ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

ИСО/МЭК 24767-2— 2018

Информационные технологии БЕЗОПАСНОСТЬ ДОМАШНЕЙ СЕТИ

Часть 2

Внутренние службы безопасности. Безопасный протокол связи для связующего программного обеспечения (SCPM)

(ISO/IEC 24767-2:2009, ЮТ)

Издание официальное

Стандартинформ

2018

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего образования «Российский экономический университет им. Г.В. Плеханова» (ФГБОУ ВО «РЭУ им. Г.В. Плеханова») на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 4 сентября 2018 г. № 558-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 24767-2:2009 «Информационные технологии. Безопасность домашней сети. Часть 2. Внутренние службы безопасности. Безопасный протокол связи для связующего программного обеспечения (SCPM)» (ISO/IEC 24767-2:2009, «Information technology — Home network security — Part 2: Internal security services — Secure communication protocol for middleware (SCPM)», IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. №162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, оформление, 2018

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

5.3.4    Независимость криптографических алгоритмов

Предполагается, что механизм SCPM позволит выбирать между различными криптографическими алгоритмами без оказания влияния на другие части его реализации, а также внедрять недавно разработанные криптографические методы для совершенствования безопасности в дальнейшем.

5.3.5    Расширяемость вариантов использования широкополосных подключений

В то время как широкополосные подключения в основном используются для доступа в Интернет сегодня, в будущем они также создают новые возможности для обслуживания, такие как обслуживание бытовой техники, контроль за домашней безопасностью или услуги, связанные с измерением. Для обеспечения будущего использования в сочетании с различными службами, которые будут применяться в домашних сетях, предполагается, что механизм SCPM будет оснащен возможностью устанавливать два или более общих ключа для бытового прибора, специфических для службы, позволяющих создание двух или более безопасных доменов в домашних сетях.

6 Безопасный протокол связи для связующего программного обеспечения (SCPM)

6.1    Общие положения

В данном пункте представлено высокоуровневое описание принципа действия протокола SCPM, чтобы показать общую картину процессов данного протокола и его поведения сточки зрения системы, а также чтобы понять, как он встраивается в коммуникацию между сетевыми узлами. В данном пункте также приводится базовое описание следующих далее пунктов, каждый из которых содержит более подробное описание каждого вопроса.

Реализация протокола SCPM, действующего в домашних приборах и контроллере приборов, обеспечивает защиту сетевого трафика. Предложенная защита основывается на требованиях, выбранных исходя из различных предположений, разъясненных в 5.3.

6.2    Суть протокола SCPM

Протокол SCPM разработан для обеспечения сочетания служб безопасности, включая конфиденциальность, аутентификацию источника данных, подлинность данных и службу антиповтора (форма частичной проверки целостности последовательности данных). Набор служб зависит от того, включен ли механизм аутентификации/шифрования или нет.

Службу конфиденциальности можно выбрать отдельно от других служб. Тем не менее, использование службы конфиденциальности без проверки подлинности/аутентификации может подвергнуть системы передачи данных некоторым формам активных атак, способных отрицательно сказаться на работе службы конфиденциальности.

Аутентификация источника данных и целостность данных являются совмещенными службами (далее по тексту — аутентификация) и предлагаются как вариант дополнения совместно (опционно) с конфиденциальностью. Службу антиповтора можно выбрать только если выбрана аутентификация источника данных, и выбор осуществляется исключительно на усмотрение принимающего устройства. (Хотя по умолчанию требуется, чтобы отправитель увеличивал порядковый номер, используемый для антиповтора. Функция работает только если приемное устройство проверяет порядковый номер.)

6.3    Принцип работы протокола SCPM

В целях минимизации размера сообщения протокол SCPM не будет применять механизм формирования пакетов данных, используемый в модели сети ИСО. Модель сети ИСО показана на рисунке 4. Вместо этого используется тот же формат сообщений с добавлением полей, таких как заголовок безопасности, порядковый номер и длина данных между адресом назначения (DA) и счетчиком байтов незашифрованной текстовой части данных (РВС) и шифрованием/аутентификацией некоторых из полей. На рисунке 2 в сравнении показаны кадр обычного сообщения и кадр безопасного сообщения. Точное определение полей будет описано в разделе 7.

На рисунке 2 также показано, что сообщения, переносимые в виде кадров, в линиях связи домашней сети можно условно разделить на два типа: незашифрованный текст и шифрованный текст, в зависимости от соответствующего флага в заголовке. Незашифрованные текстовые сообщения переносятся непосредственно в информационное наполнение в виде открытого текста, а защищенные сообщения хранятся в информационном наполнении в аутентифицированной или зашифрованной форме. 6

ГОСТ Р ИСО/МЭК 24767-2—2018

Если флаг в заголовке показывает, что кадр является безопасным, будет активирован протоколом SCPM для интерпретации зашифрованных / аутентифицированных данных информационного наполнения. В противном случае выполняются стандартные процедуры связи в обычном порядке.

Кадр обычного сообщения

Рисунок 2 — Сравнение кадров обычного и защищенного сообщений

Помимо приведенной структуры сообщений протокол SCPM также использует механизм одного законченного цикла связи для снижения объема передачи данных для сред с низкой или ограниченной пропускной способностью. Законченный цикл связи представляет собой протокол «запрос-ответ», в котором при связи между двумя узлами инициатор службы отсылает сообщение-запрос, а запрашиваемая служба возвращает сообщение-ответ. Последовательность обработки сообщений показана на рисунке 3.

6.4    Где реализуется протокол SCPM

Главная цель протокола SCPM — обеспечение механизмов достаточной защиты для широкого перечня приложений с ограниченными возможностями в плане информационных технологий, а также обеспечение безопасной связи на сетевом уровне, как показано на рисунке 4. Протокол SCPM реализуется связующим ПО защищенной связи на сетевом, транспортном и сеансовом уровнях (рисунок 4).

У кадров сетевого уровня отсутствуют механизмы обеспечения безопасности. Подделать адрес, изменить содержимое, повторить старые кадры и проверить содержимое кадров при передаче довольно легко. Поэтому нет гарантии, что:

a)    полученные пакеты отправлены заявленным отправителем;

b)    пакеты содержат исходные данные, отправленные отправителем;

c)    исходные данные не были просмотрены третьей стороной в ходе передачи.

Обеспечение защиты на сетевом уровне имеет много преимуществ. Чаще всего приложения не

нуждаются в изменениях, либо их требуется немного, поскольку они могут без проблем работать с любым протоколом, предусматривающим передачу данных на более высоком, чем сетевой, уровне, что сокращает количество вариантов реализации других протоколов безопасности на более высоких уровнях.

Поскольку протокол SCPM работает на сетевом уровне, он может использоваться для защиты любого протокола, инкапсулированного в сетевой пакет без каких-либо дополнительных требований.

6.5    Уровни применения протокола SCPM

Приложения, работающие на основе протокола SCPM, можно разделить на четыре уровня применения: администратор, пользователь, провайдер услуг и изготовитель. Каждое из применений можно проиллюстрировать следующим образом.

7

ГОСТ Р ИСО/МЭК 24767-2—2018

Уровень администратора

К этому уровню относится владелец дома, который контролирует различные уровни доступа к устройствам. Например, процедуры начальной настройки ключа пользователя располагаются на уровне администратора.

На данном уровне службы конфиденциальности и (или) аутентификация выполняются по серийному ключу устройства. Серийный ключ настраивается в устройстве при изготовлении и указывается на наружном корпусе устройства. Владелец дома, который контролирует право доступа к устройству, использует серийный ключ при первоначальной настройке ключа пользователя для доступа к устройству.

Уровень пользователя

К данному уровню относятся лица, живущие в доме и использующие автоматизацию управления домашней сетью. Ключ пользователя устанавливается в устройстве администратором; для одного домена устанавливается один ключ пользователя. Если живущие в доме лица не желают разглашать информацию кому-либо, не входящему в круг семьи, сообщения связи должны быть защищены ключом пользователя.

Уровень провайдера услуг

Если владелец дома желает передать некоторые права доступа к устройству провайдеру услуг (при необходимости развернуть службы безопасности), связь между управляющим узлом и узлом устройства защищается ключом провайдера услуг, что предотвращает управление назначенными устройствами со стороны сторонних неуполномоченных провайдеров услуг.

Уровень изготовителя

Когда изготовители выполняют определенные операции, которые требуют защиты от перехвата сообщений злоумышленниками, сообщения связи можно защитить ключом изготовителя. Ключ изготовителя контролируется изготовителем устройства.

6.6 Ключи применения протокола SCPM

Настоящий стандарт определяет следующие пять ключей протокола SCPM.

Серийный ключ

Серийный ключ используется, когда службы конфиденциальности и (или) аутентификации выполняются на уровне администратора.

Ключ пользователя

Ключ пользователя используется, когда службы конфиденциальности и (или) аутентификация выполняются на уровне пользователя.

Ключ провайдера услуг

Ключ провайдера услуг используется, когда службы конфиденциальности и (или) аутентификации выполняются на уровне провайдера услуг.

Ключ изготовителя

Ключ изготовителя используется, когда службы конфиденциальности и (или)аутентификации выполняются на уровне изготовителя.

Мастер-ключ

В настоящем стандарте мастер-ключ — обобщенное название многопользовательского секретного ключа. После обновления общего ключа такой общий ключ называют «новый мастер-ключ», а общий ключ до обновления называют «предыдущий мастер-ключ».

7 Формат кадра защищенного сообщения

7.1    Общий кадр передачи данных

7.1.1    Общие положения

Подавляющее большинство пакетов данных, проходящих сегодня через сеть, соответствуют правилам и форматам, определенным стандартами. Типовой сетевой кадр, как правило, включает заголовок сообщения и данные информационного наполнения. Так, кадр IP включает заголовок IPv4/IPv6 и передаваемые данные. В частности, заголовок сообщения включает заголовок кадра, адрес источника и адрес назначения. Передаваемые данные включают размер данных и данные приложения, как показано на рисунке 5.

HD SA DA ВС ADATA -V-

Заголовок сообщения    Передаваемые    данные

HD = заголовок кадра SA = адрес источника DA = адрес назначения ВС = счетчик байтов EDATA ADATA = данные приложения

HD SA DA ВС ADATA ^ v / ^ v J

Заголовок сообщения    Передаваемые    данные HD = заголовок кадра SA = адрес источника DA = адрес назначения ВС = счетчик байтов EDATA ADATA = данные приложения

Рисунок 5 — Кадр обычного сообщения

7.1.2    Заголовок кадра (HD)

Заголовок содержит информацию о признаке, который указывает на то, является ли кадр сообщения защищенным или нет. Кроме того, он может нести другую возможную информацию, например способ передачи данных. Типовой моделью передачи данных для сетей является модель точка-точка, но также могут использоваться другие модели, например широкополосная или многоадресная модели.

7.1.3    Адрес источника (SA) и адрес назначения (DA)

Адрес источника представляет собой сетевой адрес источника, который сгенерировал данный кадр сообщения. Адрес назначения представляет собой сетевой адрес целевой хост-системы. Это может быть IP-адрес, МАС-адрес или любая форма адресации, предусмотренная для специфической передачи данных.

7.1.4    Счетчик байтов (ВС)

Счетчик байтов показывает размер данных поля ADATA в байтах.

7.1.5    Данные приложения (ADATA)

Данные приложения — это поле переменной длины, которое несет информацию о запрашиваемом сервисе.

7.2 Структура защищенного кадра

7.2.1 Общие положения

Данные приложения далее делятся на несколько полей: защищенный заголовок (SHD), поле порядкового номера (SNF), счетчик байтов незашифрованной текстовой части данных (РВС), незашифрованные текстовые данные приложения (PADATA), код проверки блоков (ВСС), холостое заполнение (PDG) и подпись проверки подлинности данных сообщения (MDAS). Следующие подклассы определяют каждое поле защищенного кадра. Некоторые поля могут быть необязательными (отмечены * на рисунке 6), что означает, что поле может отсутствовать, если данная опция не выбрана. Выбрана опция или нет, определяется в защищенном заголовке (SHD). Структура защищенного кадра показана на рисунке 6.

HD SA DA ВС EDATA Кадр обычного сообщения / / / / / / / / / / / / / / г t / / / / / t / / / / / / / / / HD SA DA ВС SHD SNF РВС PEDATA вес PDG* MDAS*

Кадр защищенного сообщения Рисунок 6 — Кадр защищенного сообщения

ГОСТ Р ИСО/МЭК 24767-2—2018

7.2.2 Защищенный заголовок (SHD)

Защищенный заголовок представляет собой 2-байтовое поле. На рисунке 7 показан формат данных в защищенном заголовке.

ЬЗ:Ь2:Ы:Ь0 Индекс ключа ЬЗ:Ь2:Ы :Ь0=0:0:0:0 — индекс серийного ключа ЬЗ:Ь2:Ы:Ь0=0:0:0:1 — индекс ключа пользователя ЬЗ:Ь2:Ы:Ь0=0:0:1:0 — индекс ключа изготовителя Прочие: с 0:0:1:1 по 1:1:1:1 — индекс ключа провайдера услуг Ь4 1: используется для указания того, что сообщение зашифровано и аутентифицировано многопользовательским секретным ключом, который вычисляется алгоритмом Диффи-Хеллмана 0: ЬЗ:Ь2:Ы:Ь0 — применяется индекс ключа Ь5 Зарезервировано для будущего использования Ь6 Флаг службы аутентификации (Ь7:Ь6=1:1 не допускается) 0: Сертификация включена 1: Сертификация отключена Ь7 Флаг службы шифрования (Ь7:Ь6=1:1 не допускается) 0: Шифрование включено 1: Шифрование выключено Ь8 Тип сообщения 0: Запрос 1: Ответ Ь9~Ы1 Зарезервировано для будущего использования Ь15:Ы4:ЫЗ:Ы2 Ответ служб безопасности Ы5:Ь14:ЫЗ:Ы2 = 0:0:0:0: успешно Ы5:Ы4:ЫЗ:Ь12 = 0:0:0:1: ошибка проверки SNF Ы5:Ы4:Ь13:Ь12 = 0:0:1:0: ошибка проверки сертификации Ь15:Ь14:ЫЗ:Ы2 = 0:1:0:0 ошибка расшифровки данных

Рисунок 7 — Формат данных защищенного заголовка (SHD)

Биты 0-3 используются для указания индекса ключа для различных применений (администратор, пользователь, провайдер услуг и изготовитель). Поскольку для бытовой техники возможны несколько услуг, индекс ключа провайдера услуг может быть в диапазоне от (ЬЗ:Ь2:Ь1 :Ь0) = 0:0:1:1 до 1:1:1:1.

Чтобы обеспечить обновление мастер-ключа с использованием алгоритма Диффи-Хеллмана, для указания данного типа услуги используется бит 4. Если значение бита 4 задано равным 1, это означает, что данный кадр защищенного сообщения защищен многопользовательским секретным значением, вычисленным алгоритмом Диффи-Хеллмана.

Биты 6-7 показывают, включена ли служба безопасности. Если значение бита 6 задано равным 0, это означает, что в такой передаче данных включена служба аутентификации. Если значение бита 7 задано равным 0, это означает, что включена служба конфиденциальности. Биты 6 и 7 не должны одновременно равняться 1, так как если заголовок кадра сообщения указывает на то, что передача данных защищена, но не указана служба аутентификации или конфиденциальности, это приведет к конфликту со значением, указанным в поле заголовка.

Поскольку протокол SCPM представляет собой протокол типа «запрос-ответ», бит 8 указывает на свойство сообщения. Значение 0 указывает на сообщение типа «запрос» от запрашивающей стороны, а значение 1 указывает на сообщение типа «ответ» от запрашиваемой стороны.

Биты 12-15 используются для указания результата обработки сообщения-запроса и действительны в сообщении-ответе. Бит 12 указывает на коррекцию проверки поля SNF, бит 13 указывает на коррекцию проверки аутентификации, а бит 14 указывает на коррекцию прав доступа.

7.2.3 Поле порядкового номера (SNF)

Это 4-байтовое поле, которое содержит монотонно возрастающее значение счетчика (порядковый номер).

Данное поле является обязательным и всегда присутствует, даже если безопасная передача данных не включает службу антиповтора для данного кадра сообщения. Обработка поля порядкового

11

номера — в ответственности запрашиваемой службы. Исходное значение поля SNF может быть определено двумя способами — методом случайного выбора (для холодного или горячего пуска узла) или методом чтения и использования порядкового номера, хранящегося в постоянной памяти (только для горячего пуска). Запрашиваемая служба увеличивает порядковый номер на 1 и передает его в инициатор службы после успешной проверки подлинности.

Инициатор службы использует значение поля SNF в следующем сообщении-запросе к той же запрашиваемой службе.

7.2.4    Счетчик байтов незашифрованной текстовой части данных (РВС)

Счетчик РВС представляет собой 1-байтовое поле, указывающее количество байтов в незашифрованной текстовой части данных (PADATA).

7.2.5    Незашифрованные текстовые данные приложения (PADATA)

Незашифрованные текстовые данные приложения PADATA представляют собой поле переменной длины. Данное поле является обязательным и представляет целое число байт по длине. Максимальная длина поля PADATA составляет 255 байт.

7.2.6    Код проверки блоков (ВСС)

Использование механизма кода проверки блоков (ВСС) предназначено для обнаружения ошибок. Код ВСС представляет собой 1-байтовое поле, в котором хранится итоговое значение, генерируемое путем выполнения операций с исключающим ИЛИ по поперечному контролю четности каждого поля. Данные, проверяемые ВСС, включают поля: SA, DA, ВС, SHD, SNF, РВС и PADATA. Данный код проверки не является криптографической контрольной величиной.

7.2.7    Холостое заполнение (PDG)

При использовании алгоритма шифрования, требующего, чтобы незашифрованный текст имел длину, точно кратную определенному количеству байт, например размеру блока блочного шифра, поле PDG используется для заполнения незашифрованного текста (состоящего из полей: РВС, PADATA и ВСС) до размера, требуемого алгоритмом. Инициатор службы может добавлять два байта холостого заполнения. Для расширенного стандарта шифрования AES инициатор службы может добавлять от 0 до 15 байт холостого заполнения. Включение поля PDG не является обязательным, но все реализации должны поддерживать генерирование и использование холостого заполнения. Если требуются байты поля PDG, но алгоритм шифрования не указывает содержание холостого заполнения, тогда по умолчанию применяется следующая обработка данных. Поле PDG заполняется значением 0x00.

7.2.8    Подпись проверки подлинности данных сообщения (MDAS)

Подпись MDAS представляет собой поле переменной длины, длина которого указывается выбранной функцией аутентификации. Например, если применяется стандарт AES СВС-МАС со 128-битным ключом (см. ИСО/МЭК 10116), подпись MDAS представляет собой 16-байтовые данные. Поле MDAS — это значение, вычисляемое по кадру сообщения протокола SCPM, исключая заголовок (HD) и данные проверки подлинности данных (MDAS). Поле MDAS не является обязательным и включается только в случае, если служба аутентификации была выбрана и указана в поле SHD.

8 Реализация протокола SCPM

8.1    Алгоритмы и обработка данных

8.1.1    Общие положения

Несмотря на то, что и конфиденциальность, и аутентификация являются необязательными, должна быть выбрана как минимум одна из данных служб, а значит оба алгоритма шифрования и проверки подлинности не должны быть одновременно отключены.

8.1.2    Криптографические алгоритмы и криптовычисления

Используемый алгоритм шифрования указывается с распределением ключа. Протокол SCPM предназначен для использования с алгоритмами симметричного шифрования. Обязательным алгоритмом шифрования SCPM является AES. Зашифрованные поля включают поля: РВС, PADATA, ВСС и PDG. На рисунке 8 показан пример с использованием алгоритма шифрования AES-CBC с длиной ключа 128-бит.

12

ГОСТ Р ИСО/МЭК 24767-2—2018

Задать холостое заполнение для выравнивания незашифрованного текста, подлежащего шифрованию, чтобы он был кратен 16 байт

Исходный незашифрованный текст

HD SA DA ВС SHD SNF РВС PEDATA ВСС PDG Шифрование ; Г- | HD SA DA ВС SHD SNF 128 бит • • • • 128 бит

Шифрованный текст Рисунок 8 — Шифрование с применением алгоритма AES-CBC со 128-битным ключом

8.1.3    Алгоритмы аутентификации и вычисление данных аутентификации

Так же, как и для вышеупомянутых алгоритмов шифрования, алгоритмы проверки подлинности данных, используемые для вычисления данных аутентификации, должны быть специфицированы как алгоритмы с распределением ключей, которые принимают сообщение любого размера и генерируют выходное сообщение фиксированной длины. Обязательным алгоритмом проверки подлинности данных протокола SCPM является алгоритм AES. Он работает аналогично алгоритму шифрования и использует поле СВС-МАС для создания подписи, необходимой для проверки подлинности сообщения по блочному шифру. Данные аутентификации поступают из полей в кадре сообщения, а для получения необходимого значения существуют два варианта: 1) только аутентификация и 2) аутентификация после шифрования. На рисунке 9 показано, как вычисляются данные аутентификации. В случае выполнения только аутентификации данные аутентификации вычисляются от поля SA до поля ВСС и вносятся в поле MDAS. В случае включения служб аутентификации и шифрования сначала выполняется обработка шифрования (из поля РВС в поле PDG), а аутентификация вычисляется от поля БАдо зашифрованных данных и вносится в поле MDAS. Поле MDAS — это последние N байт защищенного кадра в целом, где N зависит от алгоритма аутентификации.

Для некоторых алгоритмов аутентификации строка байтов, по которой вычисляется значение данных аутентификации, должна быть кратна размеру блока, определяемому алгоритмами. Если длина строки байтов не соответствует требованиям алгоритма по размеру блока, в конце кадра аутентифицированного сообщения добавляется скрытое холостое заполнение (после поля ВСС, если выполняется только служба аутентификации, и после шифрования данных, если используются службы аутентификации и конфиденциальности) перед внесением в поле MDAS. Данные байты холостого заполнения должны иметь нулевое значение, а размер блока определяется требованиями алгоритма. Холостое заполнение не передается с кадром сообщения.

8.1.4    Режим сцепления блоков шифртекста (СВС)

Все алгоритмы шифрования, используемые в SCPM, должны работать в режиме сцепления блоков шифртекста (СВС) (см. ИСО/МЭК 10116). СВС требует, чтобы количество данных, подлежащих шифрованию, было кратным размеру блока шифртекста. Требование выполняется путем добавления холостого заполнения в конце данных при необходимости, перед шифрованием. Холостое заполнение становится частью шифрованного текста кадра сообщения и удаляется инициируемой службой в ходе обработки входящего сообщения. Если данные уже кратны размеру блока шифра, холостое заполнение добавлять не требуется.

Шифры в режиме СВС также требуют наличия вектора инициализации (IV) во избежание генерирования нового ключа для каждого сеанса шифрования. Данный вектор инициализации генерируется из значения SNF и описан в 8.1.6.

13

Последние N байт

Рисунок 9 — Вычисление данных аутентификации

8.1.5    Инициализация и проверка значения поля SNF

Инициатор службы сохраняет значение поля SNF, связанное с инициируемой службой в предыдущем успешном ответе. Инициируемая служба контролирует/управляет полем SNF для каждого инициатора служб. Но для первого запроса или в случае потери значения поля SNF по каким-либо причинам, например из-за отключения питания, инициатор службы не сохраняет последовательный номер, и инициализация поля SNF должна выполняться вместе со службой аутентификации.

Сообщение-запрос включает произвольное значение поля SNF и отправляется на противоположную сторону, как показано на рисунке 10. Если не удается проверить поле SNF, запрашиваемая служба отвечает с использованием сгенерированного/сохраненного значения поля SNF, чтобы указать на ошибку проверки поля SNF. Инициатор службы получает значение поля SNF и отправляет сообщение об аутентификации с полученным значением поля SNF. Запрашиваемая служба проверяет сообщение и затем отправляет ответ об успешной аутентификации инициатору службы с новым значением поля SNF (увеличенным на 1).

8.1.6    Вычисление значения вектора инициализации (IV)

Применение режима СВС требует наличия четко заданного вектора инициализации (IV) N байт, при этом N зависит от алгоритма. Например, 16-байтовый вектор инициализации используется в шифровании алгоритмом AES-СВС с длиной ключа 128 бит. Данный вектор инициализации превосходит по значению защищенное (зашифрованное) информационное наполнение. Включение вектора инициализации в каждом кадре сообщения гарантирует, что возможно расшифрование каждого полученного кадра сообщения, даже если некоторые кадры сообщения выпали при передаче. Значение вектора инициализации является производным от поля SNF. Например, 16-байтовый вектор инициализации используется для шифрования алгоритмом AES-СВС. На рисунке 11 показана настройка значения вектора инициализации в случае 16-байтового IV.

8.2 Обработка кадра защищенного сообщения

8.2.1 Общие положения

Обработка кадра защищенного сообщения зависит оттого, какие службы были включены.

Следующие подклассы иллюстрируют, как кадры сообщения обрабатываются в трех комбинациях:

a)    включена только проверка подлинности данных (аутентификация);

b)    включена только конфиденциальность;

c)    включены и проверка подлинности данных, и аутентификация.

Обмен защищенными сообщениями между инициатором службы и запрашиваемой службой соответствует обмену в одноранговой сети. Если указанный сетевой адрес назначения является широковещательным адресом, запрашиваемая служба должна отказаться от сообщения.

ГОСТ Р ИСО/МЭК 24767-2—2018

SNF SNF SNF SNF

Рисунок 11 — Вычисление значения вектора инициализации (IV)

8.2.2 Обработка кадра сообщения только при проверке подлинности данных

На рисунке 12 показана последовательность проверки подлинности данных между инициатором службы и запрашиваемой службой.

Шаги (номера указывают последовательность) генерирования сообщения проверки подлинности данных от инициатора службы описываются следующим образом:

a)    установка флага в поле SHD:

1)    биты Ь0:Ь1:Ь2:ЬЗ используются для указания индекса ключа, применяемого при передаче данных;

2)    биты Ь6:Ь7 = 0:1 используются для указания на службу безопасности следующим образом: аутентификация включена, а шифрование выключено;

3)    бит Ь8 = 0 используется для указания на то, что сообщение является запросом;

b)    установка порядкового номера:

1)    если порядковый номер из предыдущей передачи данных сохранился, используется именно он;

2)    в противном случае (для первой передачи данных или если порядковый номер не сохранился), используется случайным образом выбранный произвольный порядковый номер, как описано в 7.2.3;

c)    вычисление поля ВСС;

d)    вычисление поля MDAS по всему кадру сообщения, за исключением полей: HD и MDAS.

Проверка сообщения аутентификации запрашиваемой службой включает следующее шаги.

15

ГОСТ Р ИСО/МЭК 24767-2—2018

Содержание

1    Область применения....................................................................................................................................1

2    Нормативные ссылки..................................................................................................................................1

3    Термины, определения и    сокращения .......................................................................................................2

3.1    Термины и определения .......................................................................................................................2

3.2    Сокращения ...........................................................................................................................................2

4    Соответствие................................................................................................................................................3

5    Проектные решения внутренних служб безопасности для домашних сетей .........................................3

5.1    Общие положения .................................................................................................................................3

5.2    Вопросы, связанные с безопасностью.................................................................................................4

5.2.1    Общие положения ........................................................................................................................4

5.2.2    Небезопасная передача...............................................................................................................5

5.2.3    Намеренно неправильное использование .................................................................................5

5.3    Принципы разработки мер безопасности ............................................................................................5

5.3.1    Общие положения ........................................................................................................................5

5.3.2    Минимизация ресурсов для экономии расходов .......................................................................5

5.3.3    Независимость коммуникационной среды .................................................................................5

5.3.4    Независимость криптографических алгоритмов........................................................................6

5.3.5    Расширяемость вариантов использования широкополосных подключений ...........................6

6    Безопасный протокол связи для связующего программного обеспечения (SCPM) ...............................6

6.1    Общие положения .................................................................................................................................6

6.2    Суть протокола SCPM ...........................................................................................................................6

6.3    Принципы работы протокола SCPM.....................................................................................................6

6.4    Где реализуется протокол SCPM .........................................................................................................7

6.5    Уровни применения протокола SCPM..................................................................................................7

6.6    Ключи применения протокола SCPM ...................................................................................................9

7    Формат кадра защищенного сообщения....................................................................................................9

7.1    Общий кадр передачи данных...............................................................................................................9

7.1.1    Общие положения ........................................................................................................................9

7.1.2    Заголовок кадра (HD) .................................................................................................................10

7.1.3    Адрес источника (SA) и адрес назначения (DA) ......................................................................10

7.1.4    Счетчик байтов (ВС) ...................................................................................................................10

7.1.5    Данные приложения (ADATA) ....................................................................................................10

7.2 Структура защищенного кадра......................................................................................................10

7.2.1    Общие положения ......................................................................................................................10

7.2.2    Защищенный заголовок (SHD) ..................................................................................................11

7.2.3    Поле порядкового номера (SNF) ...............................................................................................11

7.2.4    Счетчик байтов незашифрованной текстовой части данных (РВС) .......................................12

7.2.5    Незашифрованные текстовые данные приложения (PADATA)...............................................12

7.2.6    Код проверки блоков (ВСС) .......................................................................................................12

7.2.7    Холостое заполнение (PDG)......................................................................................................12

7.2.8    Подпись проверки подлинности данных сообщения (MDAS) .................................................12

8    Реализация протокола SCPM....................................................................................................................12

8.1    Алгоритмы и обработка данных..........................................................................................................12

8.1.1    Общие положения ......................................................................................................................12

8.1.2    Криптографические алгоритмы и криптовычисления..............................................................12

8.1.3    Алгоритмы аутентификации и вычисление данных аутентификации....................................13

8.1.4    Режим сцепления блоков шифртекста (СВС) ..........................................................................14

8.1.5    Инициализация и проверка значения поля SNF......................................................................14

8.1.6    Вычисление значения вектора инициализации (IV) ................................................................14

8.2    Обработка кадра защищенного сообщения.......................................................................................14

8.2.1    Общие положения ......................................................................................................................14

8.2.2 Обработка кадра сообщения только при проверке подлинности данных.............................15

8.2.3 Обработка кадра сообщения только в режиме конфиденциальности...................................16

8.2.4    Обработка кадра сообщения при проверке подлинности данных и конфиденциальности .17

Шаг 1 Проверка порядкового номера.

Шаг 2 Проверка поля ВСС.

Шаг 3 Проверка данных аутентификации.

Ответное сообщение готовится следующим образом, чтобы передать его инициатору услуг. Шаги (номера указывают последовательность) генерации ответных сообщений от запрашиваемой стороны описываются следующим образом:

e)    установка флага в поле SHD:

1)    биты Ь0:Ь1:Ь2:ЬЗ используется для указания индекса ключа, применяемого при передаче данных, как и в соответствующем сообщении-запросе;

2)    биты Ь6:Ь7 = 0:1 используется для указания на службу безопасности следующим образом: аутентификация включена, а шифрование выключено, как и в соответствующем сообщении-запросе;

3)    бит Ь8 = 1 используется для указания на то, что сообщение является ответом;

4)    запись результата ответа в биты: Ь12:Ь13:Ь14:Ь15 для указания на то, является проверка успешной или нет. Если проверка успешная, задаются следующие значения битов: Ь12:Ь13:Ь14:Ь15 = 0:0:0:0;

f)    установка порядкового номера:

1)    в случае успешного ответа ставится следующий порядковый номер (увеличенный на 1);

2)    в случае ошибки ответа:

I)    если порядковый номер, соответствующий данному инициатору службы, не существует, запрашиваемая служба должна поставить исходный порядковый номер в поле SNF в ответе инициатору службы;

II)    в противном случае используется предыдущий отправленный порядковый номер;

д) установка данных информационного наполнения:

1)    при ошибке проверки подлинности данных данные из запроса копируются и вставляются в поля РВС, PADATA и ВСС из соответствующих полей сообщения-запроса;

2)    при успешной проверке подлинности данных данные ответа и соответствующий размер данных вставляются в поля PADATA и РВС и вычисляется поле ВСС;

h) вычисление поля MDAS по всему кадру сообщения, за исключением полей HD и MDAS.

На рисунке 12 показан пример кадров сообщений, использующих службу удостоверяющей подписи.

8.2.3 Обработка кадра сообщения только в режиме конфиденциальности

На рисунке 13 показана последовательность шифрования между инициатором службы и запрашиваемой службой.

Шаги по генерированию шифрованного сообщения от инициатора службы включают следующее (номера указывают последовательность):

a)    установка флага в поле SHD:

1)    биты Ь0:Ы :Ь2:ЬЗ используются для указания индекса ключа, применяемого при передаче данных;

2)    биты Ь6:Ь7 = 1:0 используются для указания на службу безопасности следующим образом: аутентификация отключена, а шифрование включено;

3)    бит Ь8 = 0 используется для указания на то, что сообщение является запросом;

b)    установка произвольного номера в поле SNF;

c)    вычисление поля ВСС;

d)    шифрование:

1)    добавление необходимых данных холостого заполнения;

2)    если используется алгоритм режима СВС, данные вектора инициации, действующие как вводные данные для алгоритма шифрования, вычисляются по значению поля SNF;

3)    шифрование результата (поля: РВС, PADATA, ВСС и PDG).

Шаги проверки шифрованного сообщения запрашиваемой службой включают следующее (номер указывает последовательность).

Шаг 1. Расшифрование данных.

Шаг 2. Проверка поля ВСС.

Сообщение-ответ подготавливается для передачи инициатору службы следующим образом:

а) установка флага в поле SHD:

1)    биты Ь0:Ь1:Ь2:ЬЗ используются для указания индекса ключа, применяемого при передаче данных, как и в соответствующем сообщении-запросе;

2)    биты Ь6:Ь7 = 1:0 используются для указания на службу безопасности следующим образом: аутентификация выключена, а шифрование включено, как и в соответствующем сообщении-запросе;

16

9 Управление ключами..................................................................................................................................19

9.1    Общие положения................................................................................................................................19

9.2    Инициализация ключей........................................................................................................................20

9.2.1    Инициализация ключа пользователя ........................................................................................20

9.2.2    Инициализация ключа провайдера услуг.................................................................................22

9.2.3    Инициализация ключа изготовителя.........................................................................................23

9.3    Обновление мастер-ключа..................................................................................................................23

9.3.1    Обновление мастер-ключа между узлом KSN и устройством ................................................23

9.3.2    Синхронизация ключа ................................................................................................................27

9.3.3    Запрос на обновление мастер-ключа от устройства ...............................................................30

Приложение А (справочное) Авторизация узла установки ключа..............................................................32

Приложение ДА (справочное) Сведения о соответствии ссылочного международного

стандарта национальному стандарту Российской Федерации.....................................33

Библиография ...............................................................................................................................................34

IV

ГОСТ Р ИСО/МЭК 24767-2—2018

Введение

ИСО (Международная организация по стандартизации) и МЭК (Международная электротехническая комиссия) образуют специализированную систему всемирной стандартизации. Государственные органы, являющиеся членами ИСО или МЭК, участвуют в разработке международных стандартов посредством технических комитетов. Участие в разработке стандарта в конкретной области может принять любой заинтересованный орган, являющийся членом ИСО или МЭК. Другие международные организации, правительственные и неправительственные, контактирующие с ИСО и МЭК, также принимают участие в работе.

В области информационных технологий ИСО и МЭК учредили Объединенный технический комитет, ИСО/МЭК СТК 1. Проекты международных стандартов, подготовленные Объединенным техническим комитетом, рассылаются национальным комитетам на голосование. Публикация в качестве международного стандарта требует утверждения не менее чем 75 % национальных комитетов, участвующих в голосовании.

Официальные решения или соглашения МЭК и ИСО по техническим вопросам выражают, насколько это возможно, международное согласованное мнение по относящимся к делу вопросам, так как каждый технический комитет имеет представителей от всех заинтересованных национальных комитетов — членов МЭК и ИСО.

Публикации МЭК, ИСО и ИСО/МЭК имеют форму рекомендаций для международного использования и принимаются национальными комитетами — членами МЭК и ИСО именно в таком понимании. Несмотря на все приложенные усилия для обеспечения точности технического содержания публикаций МЭК, ИСО и ИСО/МЭК, МЭК или ИСО не несут ответственность за то, каким образом они используются или за их неправильную трактовку конечным пользователем.

В целях обеспечения международной унификации (единой системы), национальные комитеты МЭК и ИСО обязуются обеспечить максимальную прозрачность применения международных стандартов МЭК, ИСО и ИСО/ МЭК, насколько это позволяют государственные и региональные условия данной страны. Любое расхождение между публикациями ИСО/МЭК и соответствующими национальными или региональными стандартами должно быть четко обозначено в последних.

ИСО и МЭК не предусматривают процедуры маркировки и не несут ответственность за любое оборудование, заявленное на соответствие одному из стандартов ИСО/МЭК.

Все пользователи должны удостовериться в использовании последнего издания настоящей публикации.

МЭК или ИСО, их руководство, сотрудники, служащие или представители, включая отдельных экспертов и членов их технических комитетов, а также члены национальных комитетов МЭК или ИСО не несут ответственности за несчастные случаи, материальный ущерб или иной нанесенный ущерб, прямой или косвенный, или за затраты (включая судебные издержки), понесенные в связи с публикацией или вследствие использования настоящей публикации ИСО/МЭК или другой публикации МЭК, ИСО или ИСО/МЭК.

Особого внимания требует нормативная документация, цитируемая в настоящей публикации. Использование ссылочных документов необходимо для правильного применения настоящей публикации.

Обращается внимание на то, что некоторые элементы настоящего международного стандарта могут быть объектом патентных прав. ИСО и МЭК не несут ответственности за определение какого-либо или всех таких патентных прав.

Международный стандарт ИСО/МЭК 24767-2 был разработан подкомитетом 25: «Взаимосвязь оборудования для информационных технологий» Объединенного технического комитета ИСО/МЭК 1 «Информационные технологии».

Перечень всех имеющихся в настоящее время частей серии ИСО/МЭК 24767 под общим названием «Информационные технологии. Безопасность домашней сети» представлен на сайте МЭК.

V

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

БЕЗОПАСНОСТЬ ДОМАШНЕЙ СЕТИ

Часть 2

Внутренние службы безопасности.

Безопасный протокол связи для связующего программного обеспечения (SCPM)

Information technology. Home network security. Part 2. Internal security services. Secure communication protocol for

middleware (SCPM)

Дата введения — 2019—02—01

1    Область применения

Настоящий стандарт описывает безопасность оборудования с ограниченными возможностями с точки зрения применения информационных технологий в домашних сетях. Безопасный протокол связи для связующего программного обеспечения (SCPM) прежде всего разработан для поддержки сетевой безопасности (см. 5.2) оборудования, не поддерживающего протоколы интернет-безопасности, такие как IPSec или SSL/TLS. Несмотря на то, что данный протокол разработан для незащищенной передачи, он также может использоваться для других типов передачи данных. Разумеется качественный уровень служб безопасности протокола SCPM не соответствует уровню протоколов интернет-безопасности, но обеспечивает безопасное подключение такого промежуточного программного обеспечения в рамках домашней сети.

Протокол SCPM не заменяет существующие механизмы обеспечения безопасности протоколов, которые уже были опубликованы.

Протокол SCPM обеспечивает безопасность на сетевом уровне и не основан на каком-либо особом способе передачи данных. Настоящий стандарт содержит подробные технические спецификации поддерживаемых служб безопасности, необходимые форматы сообщений, информационные потоки и обработку данных фрагментов информации, необходимые для реализации данного протокола.

Таким образом, в настоящем стандарте не рассматриваются проблемы среды данных или общей архитектуры системы безопасности и не охвачены все технологии домашних сетей. Описанный в настоящем стандарте протокол не зависит от информационной среды. В стандарте регламентируются службы безопасности на сетевом уровне для протоколов, которые не имеют конфликтующей схемы адресации на сетевом уровне. Службы безопасности сетевого уровня представлены сочетанием использования криптографических и защитных механизмов.

Каждый протокол должен содержать подробную информацию по реализации данной защиты. Для системы HES, поддерживающей более одного протокола, требуется шлюз протоколов.

Таким образом, настоящий стандарт не определяет какой-либо конкретный тип приложения, за исключением управления ключами, которое жизненно необходимо для любой службы безопасности. Тем не менее, ограничения по типам приложений, используемых с протоколом SCPM, отсутствуют.

2    Нормативные ссылки

Для пользования настоящим стандартом необходимы следующие стандарты. Для датированных ссылок применяют указанную версию ссылочного стандарта. Для недатированных— последнее издание стандарта (включая любые поправки к нему).

Издание официальное

ISO/IEC 10116, Information technology — Security techniques — Modes of operation for an n-bit block cipher (ISO/IEC 10116, Информационные технологии. Методы обеспечения безопасности. Режимы работы для n-битовых блочных шифров)

3 Термины, определения и сокращения

3.1    Термины и определения

В настоящем стандарте применены следующие термины и определения.

3.1.1    конфиденциальность: Свойство, обеспечивающее недоступность и неразглашение информации неуполномоченным лицам, организациям или процессам.

3.1.2    аутентификация данных: Служба, используемая для обеспечения корректной верификации источника данных, заявленного стороной для установления канала связи.

3.1.3    целостность данных: Свойство, подтверждающее, что данные не были изменены или уничтожены неразрешенным образом.

3.1.4    узел установки ключа: Орган, ответственный за генерирование, распространение ключей и управление ими.

3.1.5    МАС-адрес: Подслой уровня управления доступом к среде передачи канального уровня используемого протокола передачи данных.

3.1.6    кадр сообщения: Минимальный блок данных, передаваемый между узлом домашних устройств и системой управления домашними устройствами.

3.1.7    внеполосная передача данных: Использование средств передачи данных, отличающихся от тех, которые требуются для передачи данных по каналу связи.

3.1.8    запрашиваемая служба: Сетевой узел, отвечающий на служебные запросы.

3.1.9    инициатор службы: Сетевой узел, который инициирует служебные запросы.

3.1.10    аутентификация пользователя: Служба для обеспечения корректной проверки идентификационной информации, представленной участником коммуникации. При этом служба авторизации обеспечивает доступ идентифицированного и авторизованного пользователя к конкретному устройству или приложению домашней сети.

3.1.11    бытовая техника: Устройства, применяемые в повседневной жизни, например кондиционер, холодильник, и т.д.

3.2 Сокращения

В настоящем стандарте применены следующие сокращения:

ADATA    —    (Application DATA (7.1.5)) данные приложения (7.1.5);

ВС    —    (Byte Counter [data length in bytes of the following data payload (size of ADATA)]) счетчик

байтов [длина данных в байтах последующей полезной информации (размер ADATA)];

ВСС    —    (Block Check Code (7.2.6)) код проверки блоков (7.2.6);

СВС    —    (Cipher Block Chaining) сцепление блоков шифртекста;

CPU — (Central Processing Unit) центральное процессорное устройство (ЦПУ);

DA — (Destination Address (of a message frame)) адрес назначения (кадра сообщения);

DCL    —    (Data-Link Layer) канальный уровень;

DES    —    (Data Encryption Standard) стандарт шифрования данных;

DH — (Diffie-Hellman (was the first published public-key algorithm and it can be used for key distribution)) алгоритм Диффи-Хеллмана (был первым опубликованным алгоритмом шифрования с открытым ключом и может использоваться для распространения ключей);

(Denial of Services) отказ в обслуживании;

(HeaDer (of the message frame)) заголовок (кадра сообщения); (Home Electronic System) домашняя электронная система; (Internet Protocol) интернет-протокол;

IPSec — (IP Security protocol) протокол безопасности Интернет-протокола;

2

ГОСТ Р ИСО/МЭК 24767-2—2018

(Internet Protocol version 4) Интернет-протокол, версия 4;

(Internet Protocol version 6) Интернет-протокол, версия 6;

(Initialisation Vector) вектор инициализации (синхропосылка);

(Key Setting Node) узел установки ключа;

(Message Authentication Code) код проверки подлинности сообщения;

(Message Data Authentication Signature) подпись проверки подлинности данных сообщения;

(Plain text data part Byte Counter (data length in bytes of the following data) счетчик байтов незашифрованной текстовой части данных (длина данных в байтах последующей полезной информации (размер ADATA));

(PaDdinG) холостое заполнение (дополнение);

(Plain text Application DATA) незашифрованные текстовые данные приложения;

(Personal Identification Number) персональный идентификационный код;

(Source Address (of a message frame)) адрес источника (кадра сообщения);

(Secure Communication Protocol for Middleware) безопасный протокол связи для промежуточного программного обеспечения;

(Secure Header) защищенный заголовок;

(Sequence Number Field) поле порядкового номера;

(Secure Sockets Layer) уровень защищенных сокетов;

(Transport Layer Security) протокол безопасности транспортного уровня;

(exclusive OR) исключающее ИЛИ.

4    Соответствие

В соответствии с настоящим стандартом применимо нижеследующее:

a)    структура должна соответствовать требованиям, изложенным в разделе 6;

b)    формат кадра сообщения должен соответствовать техническим требованиям, изложенным в разделе 7;

c)    алгоритмы и процедуры обработки должны соответствовать техническим требованиям, изложенным в разделе 8;

d)    управление ключами должно соответствовать техническим требованиям, изложенным в разделе 9. Это достигается путем обеспечения соответствия инициализации ключа техническим требованиям 9.2.1.

5    Проектные решения внутренних служб безопасности для домашних сетей

5.1 Общие положения

По мере того, как все большее количество бытовых приборов подключается к домашним сетям, жители домов все больше беспокоятся о безопасности своего имущества. Таким образом, одна из наиболее актуальных исследовательских проблем, которые нужно решить для удовлетворения потребностей пользователей — это обеспечение безопасности. И, если проблема защиты от внешних угроз сегодня довольно успешно решается с использованием таких решений, как протоколы IPSec или SSL/TLS (см. Библиографию спецификаций SSL/TLS), то проблема защиты от внутренних угроз по-прежнему остается нерешенной из-за нескольких изменяющихся критериев. Настоящий стандарт определяет требования к службам внутренней безопасности для домашних электронных систем и домашних сетей.

Внутренняя домашняя сеть требует защиты. Однако не все оборудование, находящееся в доме под контролем, нуждается в одинаковой защите. Можно предусмотреть как минимум три уровня защиты. Некоторое оборудование поддерживает полный стек IP-протоколов с различными протоколами защиты, при том что другие устройства являются независимыми, и поэтому для них защита может не требоваться вообще. Помимо двух данных категорий существует оборудование, которое нуждается в

3

защите, но не поддерживает полный комплект протоколов IP. Цель настоящего стандарта — обеспечить защиту такого промежуточного оборудования, которое не поддерживает протоколы IP. Протокол SCPM обеспечивает различные службы безопасности на сетевом уровне и не зависит от среды данных, защищая таким образом коммуникации от вторжений во внутреннюю домашнюю сеть.

Для применения мер защиты через Интернет для бытовой техники можно адаптировать существующие решения, такие как протоколы IPSec или SSL/TLS. Комбинация протокола SCPM и существующих решений, настроенных надлежащим образом, в сочетании с технологией межсетевой защиты удовлетворит критериям низкой стоимости и сложности, и будет причинять минимальные неудобства, обеспечивая при этом качественную защиту дома от угроз.

На рисунке 1 показан пример комбинированныхтехнологий защиты. Центр технического обслуживания пытается обновить программное обеспечение бытовой техники, например стиральной машины. Однако стиральная машина без поддержки протоколов IPSec или SSL не сможет обеспечить защиту данных в линии передачи при связи с сервером в центре техобслуживания. Линию разграничения можно провести между двумя сегментами, от сервера центра техобслуживания до контроллера (с поддержкой IP протокола) в доме и от контроллера до стиральной машины. Протоколы IPSec или SSL/TLS используются для защиты сегмента (от сервера центра техобслуживания до контроллера), а протокол SCPM используется для защиты второго сегмента (от контроллера до стиральной машины). Контроллер отвечает за дешифрование кодов, переданных с сервера с защитой протоколом IPSec или SSL/ TLS, и повторное шифрование сообщений с использованием протокола SCPM. Стиральная машина, поддерживающая протокол SCPM, может дешифровать данные и в конечном итоге получить код, переданный с сервера. Поскольку домашняя сеть защищена межсетевым экраном, взломщик не может проникнуть в сеть и получить переданный код, пока контроллер занят его дешифрованием и повторным шифрованием.

Защита межсетевым экраном

Настоящий стандарт предлагает решение для субкомпонентов, которые содержат устройства без IP в составе домашней электронной сети. Протоколы IPsec и TLS обеспечивают решение для устройств с поддержкой IP в составе домашней электронной сети.

5.2 Вопросы, связанные с безопасностью

5.2.1 Общие положения

В домашних сетях существует множество угроз безопасности. Цель служб безопасности — защита от злонамеренных/угрожающих факторов, которые стремятся нарушить информационную безопасность дома. Будучи направленными на сетевую передачу данных в доме, следующие факторы определяют требования к внутренней безопасности дома.

4

ГОСТ Р ИСО/МЭК 24767-2—2018

5.2.2    Небезопасная передача

Линия электропитания

-    В большинстве домов имеются подключенные к электросети устройства, а дома по соседству обычно подключены к той же «подсети электропитания», которая подключена к тому же распределительному трансформатору. Таким образом, команды по линии электропитания из одного дома потенциально могут достичь устройства в другом доме по соседству и мешать управлению этими устройствами. Данный фактор также делает возможным перехват информации.

Беспроводная связь

Беспроводная сеть — это, пожалуй, самый привлекательный подход к созданию домашней сети, поскольку она позволяет избежать затрат и сложностей, связанных с проводкой. Тем не менее, она обладает и изъяном в безопасности. Взломщикам больше не требуется физический доступ к сетевой среде, вместо этого они могут просто перехватить передачу данных от другого пользователя в радиусе действия/вещания транслирующего узла.

Суть небезопасной среды передачи данных делает домашние сети уязвимыми для различных атак, таких как пассивный перехват информации, активное вмешательство, утечка «секретной» информации, искажение данных, имитация и отказ от обслуживания.

5.2.3    Намеренно неправильное использование

Несмотря на то, что службы безопасности по настоящему стандарту сосредоточены в доме, при использовании небезопасной среды передачи рассматриваемая область более не ограничивается границами дома. Службы безопасности должны защищать от получения доступа посторонними лицами к информации, передаваемой в пределах дома, и от возможности влиять на такие фрагменты информации или манипулировать ими.

Для выполнения требований к обеспечению безопасности связи в домашней сети главный акцент необходимо сделать на следующих четырех наиболее сложных требованиях:

-    конфиденциальность — информация должна быть доступна только авторизованным лицам. Данная функция защищает данные от несанкционированного разглашения;

-    аутентификация источника данных и подлинность данных — аутентификация источника данных обеспечивает проверку источников поступления данных на соответствие запросу. Тем не менее, данная функция не может обеспечить защиту от дублирования или изменения данных. В этом случае подлинность данных должна проверяться совместно с аутентификацией источника данных;

-    антиповтор — обеспечивает безопасность кадра сообщения, делая невозможным перехват кадра сообщения хакером и внесение измененных кадров в поток данных между узлом источника и узлом назначения;

-    управление доступом — обеспечивает защиту ресурсов системы от несанкционированного доступа.

5.3    Принципы разработки мер безопасности

5.3.1    Общие положения

Принимая во внимание тот факт, что механизм SCPM планируется реализовывать в бытовых приборах с ограниченными ресурсами, таких как бытовые приборы с 8-битным ЦПУ, а также то, что безопасность жилого здания должна быть гибкой, особое внимание было уделено следующим вопросам, направленным на предоставление владельцу возможности выбирать между удобством, риском и затратами.

5.3.2    Минимизация ресурсов для экономии расходов

Предполагается, что механизм SCPM будет реализован настолько легко, насколько это возможно при имеющихся ограниченных аппаратных ресурсов (производительность ЦПУ и объем памяти). Указанные выше ограничения затрудняют реализацию в полном объеме и на длительный срок общепринятых мер безопасности, существующих в сфере информационных технологий, которые обычно требуют большого объема вычислений.

5.3.3    Независимость коммуникационной среды

Существует много типов сред передачи данных, используемых в домах для подключения различных устройств к сети. Механизмы, указанные в разделе 6, являются независимыми от среды передачи данных. Данные механизмы дают возможность гибкого использования служб и одновременно обеспечивают их безопасность.

5