Получите образец ТУ или ГОСТа за 3 минуты

Получите ТУ или ГОСТ на почту за 4 минуты

ГОСТ Р ИСО 9735-5-2012

ГОСТР

исо

9735-5-

2012

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

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT)

Синтаксические правила для прикладного уровня (версия 4, редакция 1)

Часть 5

Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника)

ISO 9735-5:2002

Electronic data interchange for administration, commerce and transport (EDIFACT) —

Application level syntax rules (Syntax version number: 4, Syntax release number: 1) —

Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of

origin)

(IDT)

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

Москва

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

2014

Предисловие

1    ПОДГОТОВЛЕН ЗАО «Проспект» совместно с Ассоциацией автоматической идентификации «ЮНИСКАН/ГС1 РУС» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 55 «Терминология, элементы данных и документация в бизнес-процессах и электронной торговле»

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

4    Настоящий стандарт идентичен международному стандарту ИСО 9735-5:2002 «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 5. Правила защиты для пакетного ЭОД1} (аутентичность, целостность и неотказуемость источника)» (ISO 9735-5:2002 «Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin»).

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок – в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).

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

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

11 ЭОД- электронный обмен данными соответствует английскому EDI – electronic data interchange.

ГОСТРИСО 9735-5 -2012

–    результат, вычисленный путем прямой обработки сообщения/пакета по алгоритму, определенному в сегменте USA внутри группы сегментов 1 из группы заголовка защиты, или

–    результат, подтвержденный электронной подписью с помощью асимметричного алгоритма, который задан в сегменте USA внутри группы сегментов 2 из группы сегментов заголовка защиты, результат хеширования сообщения/пакета по алгоритму, определенному в сегменте USA внутри группы сегментов 1 из группы сегментов заголовка защиты.

5.1.5 Область защиты

Допускается использовать два варианта применения области защиты:

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

Отсчет знаков группы сегментов заголовка защиты следует начинать с его первого знака (от буквы “U”) и заканчивать разделителем включительно, следующим за этой группой сегментов, а тело сообщения или объект – с первого знака после разделителя, завершающего последнюю группу сегментов заголовка защиты, до разделителя, предшествующего первому знаку первой группы сегментов окончания защиты, включительно.

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

Рисунок 3 иллюстрирует этот случай (область применения служб защиты, определенная в

и

N

Группа 3

Группа 2

Г руппа 1

ТЕЛО

Г руппа 1

Группа 2

Группа 3

Н/

сегментов

сегментов

сегментов

СООБЩЕ-

сегментов

сегментов

сегментов

и

заголовка

заголовка

заголовка

НИ Я/

окончания

окончания

окончания

N

О

защиты

защиты

защиты

ОБЪЕКТ

защиты

защиты

защиты

Рисунок 3 – Схематическое представление области защиты (только группа сегментов заголовка защиты и тело сообщения/объекта)

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

Рисунок 4 иллюстрирует этот случай (область применения служб защиты, определенной в заголовке защиты 2, выделена темно-серым цветом). ___

UN

Группа 3

Группа 2

Группа 1

ТЕЛО

Группа 1

Группа 2

Группа 3

и

N

Н/

сегментов

сегментов

сегментов

СООБЩЕ-

сегментов

сегментов

сегментов

Т/

UN

заголовка

заголовка

заголовка

НИ Я/

окончанияз

окончанияз

окончания

и

О

защиты

защиты

защиты

ОБЪЕКТ

ащиты

ащиты

защиты

N

Р

Рисунок 4 – Схематическое представление области защиты (от группы сегментов заголовка

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

защиты до группы сегментов окончания защиты)

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

В обоих случаях связь между группой сегментов заголовка защиты и соответствующей группой сегментов окончания защиты должна обеспечиваться элементами данных «справочный номер защиты» в сегментах USH и UST.

5.2 Принципы использования

5.2.1 Выбор служб защиты

Группа сегментов заголовка защиты может содержать в себе следующую общую информацию:

–    применяемые службы защиты;

–    идентификаторы взаимодействующих сторон;

7

ГОСТ Р ИСО 9735-5 – 2012

–    используемый механизм защиты;

–    уникальный идентификатор (порядковый номер и/или отметка времени);

–    требование неотказуемости приема.

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

5.2.2    Аутентичность

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

Служба защиты аутентификации источника должна быть определена в сегменте USH, а алгоритм – в сегменте USA группы сегментов 1; алгоритм должен быть симметричным.

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

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

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

5.2.3    Целостность

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

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

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

Эта служба может рассматриваться как промежуточный результат-службы аутентификации источника или службы неотказуемости источника.

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

5.2.4    Неотказуемость источника

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

Служба защиты, обеспечивающая неотказуемость источника, должна быть определена в сегменте USH, алгоритм хеширования – в сегменте USA группы сегментов 1, а асимметричный алгоритм электронной подписи – в сегментах USA группы сегментов 2, при использовании сертификатов.

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

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

Рассмотренная служба должна обеспечить также целостность контента и аутентификацию источника.

5.3 Внутреннее представление информации и фильтры для обеспечения соответствия синтаксическим правилам EDIFACT

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

8

ГОСТРИСО 9735-5 -2012

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

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

6 Правила использования групп сегментов заголовка и окончания защиты обмена и группы для пакетного ЭОД

6.1    Защита на уровнях групп и обменов (комплексная защита сообщений)

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

Методы защиты, рассмотренные в предыдущем разделе применительно к сообщениям/пакетам, могут также использоваться применительно к обменам и группам.

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

Если защита применяется на уровне сообщения/пакета, защищаемой структурой является тело сообщения или объект. На уровне групп защищаемой структурой является набор сообщений/пакетов внутри группы, включая все заголовки и окончания сообщений/пакетов. На уровне обмена объектом защиты является совокупность сообщений/пакетов или групп в рамках обмена, включая все заголовки и окончания сообщений/пакетов или групп.

6.2    Группы сегментов заголовка и окончания защиты

На рисунке 5 приведена схема обмена, при которой обеспечена защита как на уровне обмена, так и на уровне групп.

Рисунок 5 – Схематическое представление обмена, обеспечивающее защиту как на уровне обмена,так и на уровне групп

9

ГОСТ Р ИСО 9735-5 – 2012

6.3 Структура, образуемая группами сегментов заголовка и окончания защиты

S

R

м

1

с

99

м

1

I

с

3

I

с

2

—-+

I

м

1

I

I

с

3

I

I

с

1

—+

ТЕГ

Наименование

UNB

Заголовок обмена

Группа сегментов

1

USH

Заголовок защиты

USA

Алгоритм защиты

Группа сегментов

2

use

Сертификат

USA

Алгоритм защиты

USR

Результат защиты

Группа (группы) или

сообщение (сообщения)/пакет (пакеты)

Группа сегментов п

——- С

99

—-+

UST

Окончание защиты

М

1

I

USR

Результат защиты

С

1

—-+

UNZ

Окончание обмена

М

1

Таблица 4 – Группы сегментов заголовка и окончания защиты (безопасность только на уровне группы)

Наименование

S

R

Заголовок группы

м

1

-|—1-_ . _ “1

Q Q

1 руппа. сегментов i

у z>

Заголовок защиты

м

i

I

Алгоритм защиты

с

3

I

Группа сегментов 2 ———

—– с

2

—-+

I

Сертификат

м

1

I

I

Алгоритм защиты

с

3

I

I

Результат защиты

с

1

— +

Сообщение (сообщения)/пакет

(пакеты)

Группа сегментов п ———

—– С

99

—-+

Окончание защиты

М

1

I

Результат защиты

С

1

—-+

Окончание группы

М

1

Таблица 3 – Группы сегментов заголовка и окончания защиты (безопасность только на уровне обмена)

ТЕГ

UNG

USH

USA

USC

USA

USR

UST

USR

UNE

Примечание – Полное описание спецификаций сегментов и элементов данных, включая сегменты заголовка обмена UNB, окончания обмена UNZ, заголовка группы UNG и окончания группы UNE приведено в ИСО 9735-10. В настоящем стандарте они не детализируются.

6.4 Область защиты

Допускается использовать два варианта применения области защиты:

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

Отсчет знаков группы сегментов заголовка защиты следует начинать с первого знака (с буквы “U”) и заканчивать разделителем включительно, следующим за этой группой сегментов, а группа(группы) или сообщение(ия) /пакет(пакеты) – с первого знака после разделителя,

ГОСТ Р ИСО 9735-5 – 2012

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

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

Рисунки 6 и 7 иллюстрируют этот случай (область применения службы защиты, определенная в заголовке защиты 2, выделена темно-серым цветом)._

и

N

В

Группа 3 сегментов

Группа 2 сегмент ов

Группа 1 сегментов

ГРУППА

(ГРУППЫ)

ИЛИ

СООБЩЕНИЕ

(СООБЩЕНИЯ)/

ПАКЕТ

(ПАКЕТЫ)

Группа 1 сегментов

Группа 2 сегментов

Группа 3 сегментов

и

заголовка

заголовк

заголовка

окончанияз

окончания

окончания

NZ

защиты

а

защиты

защиты

ащиты

защиты

защиты

Рисунок 6 – Схематическое представление области защиты: только группа сегментов заголовка защиты и группа (группы) или сообщение(ия) / пакет (пакеты)_

1 1

Группа 3 сегментов заголовка защиты

Группа 2 сегментовза головка защиты

Группа 1 сегменто в

заголовка

защиты

СООБЩЕНИЕ (СООБЩЕНИЯ)/П АКЕТ (ПАКЕТЫ)

Группа 1 сегментов окончания защиты

Группа 2 сегменто вокончан иязащит ы

Группа 3 сегменто вокончан иязащиты

и

N

Е

Рисунок 7 – Схематическое представление области защиты: только группа сегментов заголовка защиты и сообщение(ия) / пакет (пакеты)

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

Эта область должна включать в себя каждый знак – от первой буквы “U” текущей группы сегментов заголовка защиты до разделителя, предшествующего первому знаку соответствующей группы сегментов окончания защиты, включительно.

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

и

N

В

Группа 3 сегментов заголовка

защиты

Группа 2 сегментов заголовка защиты

Г руппа 1 сегментов заголовка защиты

ГРУППА (ГРУППЫ) ИЛИ СООБЩЕНИЕ (СООБЩЕН ИЯ)/ПА КЕТ(ПАКЕТЫ)

Г руппа 1 сегментов окончанияза щиты

Г руппа 2 сегментов окончанияза щиты

Г руппа 3 сегментов окончанияз ащиты

Рисунок 8 – Схематическое представление области защиты (от группы сегментов заголовка защиты до группы сегментов окончания защиты)_

Г руппа 3 сегментов заголовка защиты

Г руппа 2 сегментов заголовка защиты

Г руппа 1 сегментов заголовка защиты

СООБЩЕНИЕ (СООБЩЕН ИЯ )/ПАК ЕТ(Ы)

Г руппа 1 сегментов окончанияз ащиты

Г руппа 2 сегментов окончанияз ащиты

Г руппа 3 сегментов окончанияз ащиты

Рисунок 9 – Схематическое представление области защиты (от группы сегментов заголовка защиты до группы сегментов окончания защиты)

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

В обоих случаях связь между группой сегментов заголовка защиты и соответствующей группой сегментов окончания защиты должна обеспечиваться элементами данных «справочный номер защиты» в сегментах USH и UST.

11

Приложение А (справочное)

Угрозы безопасности EDIFACT и технические решения проблемы

А.1 Введение

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

А.2 Угрозы безопасности

Хранение и передача сообщений/пакетов EDIFACT в электронной среде подвержены целому ряду угроз, к числу которых относятся:

–    несанкционированное раскрытие информации, содержащейся в сообщениях и пакетах;

–    умышленное внедрение посторонних сообщений/пакетов;

–    копирование, утеря или воспроизведение сообщений/пакетов;

–    внесение изменений в содержимое сообщения/пакета;

–    уничтожение сообщений/пакетов;

–    отрицание отправителем или получателем сообщения/пакета факта его передачи или приема.

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

А.З Защитные решения — основные службы и принципы их использования

А.3.1 Общие положения

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

Прежде всего, важно однозначно идентифицировать взаимодействующие стороны, вовлеченные в обеспечение защиты сообщений/пакетов: инициатора защиты (далее – отправитель), который перед передачей сообщения/пакета осуществляет его защиту, и адресата защиты (далее -получатель), который выполняет проверку полученного сообщения/пакета. Эти стороны могут быть идентифицированы в сегментах защиты. При применении асимметричных алгоритмов защиты такая идентификация может быть реализована путем использования так называемых «сертификатов» (в действительности это может быть либо сам сертификат, либо его учетный номер), описание которых приведено ниже.

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

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

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

Требования и методы, предназначенные для защиты сообщений/пакетов, групп или обменов EDIFACT, приведены ниже.

А.З.2 Целостность цепочки

Целостность цепочки обеспечивает защиту от копирования, дополнения, изъятия, потери или воспроизведения структуры EDIFACT (сообщения/пакета, группы или обмена).

Для обнаружения потери сообщений/пакетов, групп или обменов:

–    отправитель может включить, а получатель проверить порядковый номер (относящийся к потоку сообщений/пакетов мехщу двумя участвующими сторонами);

–    отправитель может запросить подтверждение приема (квитирование) и проверить его правильность.

12

ГОСТ Р ИСО 9735-5 – 2012

Для обнаружения добавленных или дублированных сообщений/пакетов, групп или обменов:

–    отправитель может включить, а получатель проверить порядковый номер;

–    отправитель может включить, а получатель проверить отметку времени.

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

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

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

А.3.3 Целостность информационного содержимого

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

Защита может быть обеспечена отправителем посредством введения контрольного параметра целостности. Значение этого параметра вычисляют с помощью надлежащего криптографического алгоритма, в частности такого, как MDC [ModificationDetectionCode (код для обнаружения изменений)]. Так как это контрольное значение само по себе не защищено, к нему должны применяться дополнительные меры защиты, такие как пересылка контрольного значения по отдельному каналу или вычисление цифровой подписи с целью получения гарантии неотказуемости источника. Как вариант, на целостность содержимого может влиять аутентификация отправителя, выполняемая с использованием кода аутентификации сообщения. В этом случае получатель с помощью соответствующих алгоритмов и параметров вычисляет контрольное значение параметра целостности реально принятых данных и сравнивает результат вычисления с полученным контрольным значением.

В рамках ЭОД обеспечение целостности содержимого обычно является производным результатом аутентификации источника или неотказуемости источника.

А.3.4 Аутентификация источника

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

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

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

В большинстве случаев рекомендуется иметь хотя бы службу аутентификации источника.

А.3.5 Неотказуемость источника

Неотказуемость источника защищает получателя сообщения/пакета, группы или обмена от отказа отправителя от факта посылки этих структур.

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

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

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

А.3.6 Неотказуемость приема

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

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

13

ГОСТ Р ИСО 9735-5 – 2012

А.3.7 Конфиденциальность содержимого

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

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

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

Требования к службе конфиденциальности установлены в ИСО 9735-7.

А.3.8 Взаимосвязь служб защиты

сохранению целостности контента. Взаимосвязи служб приведены в таблице А.1. Таблица А.1—Взаимосвязь служб_

Служба защиты

влечет за собой также обеспечение

целостности содержимого

аутентификации источника

неотказуемости

источника

Целостность

содержимого

Да

Аутентификация

источника

Да

Да

Неотказуемость

источника

Да

Да

Да

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

14

ГОСТ Р ИСО 9735-5 – 2012

Приложение В (справочное)

Способы защиты структуры EDI FACT

В.1 Общие положения

В данном приложении описаны некоторые из основополагающих этапов обеспечения безопасности структур EDIFACT: сообщений/пакетов, групп и обменов. Подробное описание и объяснение принципов защиты приведено в приложении А настоящего стандарта, а также в ИСО 7498-2, ИСО/МЭК 9594-8 и в документе CCITT Х.509.

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

–    целостность содержимого,

–    аутентификация источника и

–    неотказуемость источника.

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

Такие взаимосвязи указаны в таблице А.1 приложения А. С учетом приведенных в ней взаимосвязей отправитель должен выбрать не более одной из трех указанных служб.

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

В.2 Двустороннее соглашение об обмене или привлечение третьей стороны

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

Минимальным требованием должно быть заключение с каждым из партнеров отдельного двустороннего соглашения об использовании служб защиты, конкретных алгоритмов, кодов, методов управления ключами, действий в случае ненадлежащего поведения и т. п. Образец подобного соглашения доступен в рамках программы TEDIS Европейской комиссии. При таком подходе в сообщение/пакет должен быть включен небольшой объем информации, касающейся обеспечения защиты.

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

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

В.З Практические аспекты

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

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

В.4 Процедура конструирования защищенной структуры EDIFACT

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

15

ГОСТ Р ИСО 9735-5 – 2012

лица, имеющие закрытые ключи. Делать это сразу после создания структуры EDIFACT не обязательно.

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

В.5 Последовательность применения служб защиты

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

В.6 Защита отдельным сообщением на уровне сообщений/пакетов

В.6.1 Требования бизнеса

Существуют два следующих требования бизнеса к данной функциональной возможности:

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

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

Эти требования могут быть выполнены путем использования сообщения для защищенной аутентификации и защищенного квитирования AUTACK, подробно описанного в ИСО 9735-6.

В.6.2 Защита отдельным сообщением, используемая отправителем

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

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

В.6.3 Защита отдельным сообщением, используемая получателем

Такое использование сообщения AUTACK ориентировано на обеспечение неотказуемости приема. Подробное описание сообщения AUTACK приведено в ИСО 9735-6.

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

В.7 Защита отдельным сообщением на уровнях групп или обменов

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

Существуют два требования бизнеса к данной функциональной возможности:

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

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

Эти требования могут быть выполнены путем использования сообщения защищенной аутентификации и защищенного квитирования AUTACK, подробно описанного в ИСО 9735-6.

16

ГОСТ Р ИСО 9735-5 – 2012

Содержание

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

2    Соответствие стандарту………………………………………………………………………………….. 1

3    Нормативные ссылки……………………………………………………………………………………………………… 1

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

5    Правила использования групп сегментов заголовка и окончания защиты

для пакетного ЭОД…………………………………………………………………………………………………………. 2

6    Правила использования групп сегментов заголовка и окончания защиты обмена и группы

для пакетного ЭОД……………………………………………………………………………………………………………. 9

Приложение А (справочное) Угрозы безопасности EDIFACT и

технические решения проблемы………………………………………………………………… 12

Приложение В (справочное) Способы защиты структуры EDIFACT……………………………………. 15

Приложение С (справочное) Примеры защиты сообщений………………………………………………… 17

Приложение D (справочное) Функции фильтрации для наборов графических

знаков UN/EDIFACT уровней А и С……………………………………………………………… 26

Приложение Е (справочное)    Службы и алгоритмы защиты……………………………………………….. 28

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

международных стандартов ссылочным национальным

стандартам Российской Федерации…………………………………………………. 35

Библиография…………………………………………………………………………………………………………………… 36

ГОСТ Р ИСО 9735-5 – 2012

Приложение С (справочное) Примеры защиты сообщений

С.1 Введение

В данном приложении приведены три примера применений служебных сегментов защиты.

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

Пример 1. Аутентификация источника сообщения

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

Пример 2. Неотказуемость источника (первый метод)

Данный пример показывает, как служебные сегменты защиты могут использоваться в случае применения асимметричного алгоритма защиты для обеспечения неотказуемости источника. Алгоритмом, применяемым непосредственно к передаваемому сообщению является функция хеширования, которая не требует предварительного обмена ключами между партнерами. Значение хеш-функции подписывается с использованием ассиметричного алгоритма. Открытый ключ, необходимый получателю для проверки подписи в сообщении, включают в сегмент сертификата, который передается в группе сегментов заголовка защиты сообщения. Этот сертификат должен быть подписан его издателем («органом сертификации») и должен содержать открытый ключ органа сертификации для предоставления любому из партнеров возможности проверить целостность и подлинность сертификата.

Пример 3. Неотказуемость источника (второй метод)

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

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

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

Данный метод используют банки Франции в рамках системы ЕТЕВАС 5 (защищенная система передачи файлов между банками и корпоративными клиентами).

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

С.2 Пример 1. Аутентификация источника сообщения

С.2.1 Краткое описание

Компания А поручает Банку А (код 603000) списать с ее счета №00387806 сумму 54345,10 фунтов стерлингов 9 апреля 1996 г. Эта сумма должна быть переведена в Банк В (код 201827) на счет № 00663151 Компании В, находящейся по адресу WestDock, MilfordHaven. Платеж производится на основании выставленного счета № 62345. Контактное лицо получателя платежа – м-р Джонс, отдел продаж.

Банк А требует, чтобы платежное поручение было защищено функцией защиты «аутентификация источника сообщения», которая осуществляется путем генерирования отправителем сообщения так называемого «кода аутентификации сообщения» (MAC) с помощью

17

Введение

Настоящий стандарт включает в себя правила прикладного уровня для структурирования данных в рамках обмена электронными сообщениями в открытой среде, с учетом требований пакетной или интерактивной обработки. Эти правила утверждены Европейской экономической комиссией Организации Объединенных Наций (UN/ECE) в качестве синтаксических правил электронного обмена данными в управлении, торговле и на транспорте (EDIFACT) и являются частью «Справочника по обмену торговыми данными Организации Объединенных Наций» (UNTDID1*), который содержит также рекомендации по разработке сообщений пакетного и интерактивного обмена.

Спецификации и протоколы связи не входят в область распространения настоящего стандарта.

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

Комплекс стандартов ИСО 9735 состоит из следующих частей, имеющих общий подзаголовок «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1)»:

—    часть 1. Синтаксические правила, общие для всех частей;

—    часть 2. Синтаксические правила, специфичные для пакетного ЭОД;

—    часть 3. Синтаксические правила, специфичные для интерактивного ЭОД;

—    часть 4. Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения — CONTRL);

—    часть 5. Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника);

—    часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения — AUTACK);

—    часть 7. Правила защиты для пакетного ЭОД (конфиденциальность);

—    часть 8. Ассоциированные данные в ЭОД;

—    часть 9. Сообщение для управления ключами и сертификатами защиты (тип сообщения — KEYMAN);

—    часть 10. Справочники служебных синтаксических структур.

11 UNTDID – United Nations Trade Data Interchange Directory. IV

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

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT) Синтаксические правила для прикладного уровня (версия 4, редакция 1)

Часть 5

Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника)

Electronic data interchange for administration, commerce and transport (EDIFACT) —

Application level syntax rules (Syntax version number: 4, Syntax release number: 1) —

Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)

Дата введения – 2014-01-01

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

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

2    Соответствие стандарту

Для соответствия обмена настоящему стандарту в обязательном элементе данных 0002 (номер версии синтаксических правил) следует использовать номер версии “4”, а в условном элементе данных 0076 (номер редакции синтаксических правил) должен быть указан номер редакции “01”. Каждый из этих элементов данных входит в сегмент UNB (заголовок обмена). В обменах, в которых продолжает использоваться синтаксис более ранних версий, для различения соответствующих синтаксических правил, необходимо указывать следующие номера версий:

ИСО 9735:1988 – номер версии синтаксических правил: 1;

ИСО 9735:1988 (с изменениями, принятыми в 1990 г.) – номер версии синтаксических правил:2;

ИСО 9735:1988 (с изменением 1, принятым в 1992 г.) – номер версии синтаксических правил: 3;

ИСО 9735:1998 – номер версии синтаксических правил: 4.

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

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

Устройства, поддерживающие настоящий стандарт, признаются соответствующими ему, если эти устройства способны формировать и/или интерпретировать данные, структурированные и представленные в соответствии с требованиями настоящего стандарта.

Соответствие настоящему стандарту включает в себя также соответствие частям 1, 2, 8 и 10 комплекса стандартов ИСО 9735.

Положения стандартов, указанных в настоящем стандарте, являются составными элементами критериев соответствия настоящему стандарту.

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

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

ИСО 9735-1:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 1.

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

ГОСТ Р ИСО 9735-5 – 2012

Синтаксические правила, общие для всех частей (ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules common to all parts)

ИСО 9735-2:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 2. Синтаксические правила, специфичные для пакетного ЭОД (ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific to batch EDI)

ИСО 9735-6:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения — AUTACK) (ISO 9735-6:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 6: Secure authentication and acknowledgement message (message type — AUTACK))

ИСО 9735-7:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 7. Правила защиты для пакетного ЭОД (конфиденциальность) (ISO 9735-7:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 7: Security rules for batch EDI (confidentiality))

ИСО 9735-8:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 8. Ассоциированные данные в ЭОД (ISO 9735-8:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 8: Associated data in EDI)

ИСО 9735-10:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 10. Справочники служебных синтаксических структур (ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 10: Syntax service directories)

ИСО/МЭК 10181-2:1996 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы аутентификации (ISO/IEC 10181-2:1996 Information technology — Open Systems Interconnection — Security frameworks for open systems: Authentication framework)

ИСО/МЭК 10181-4:1997 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы неотказуемости (ISO/IEC 10181-4:1997, Information technology — Open Systems Interconnection — Security frameworks for open systems: Nonrepudiation framework)

ИСО/МЭК 10181-6:1996 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы целостности (ISO/IEC 10181-6:1996, Information technology — Open Systems Interconnection — Security frameworks for open systems: Integrity framework)

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

В настоящем стандарте применены термины, определенные в ИСО 9735-1.

5    Правила использования групп сегментов заголовка и окончания защиты для пакетного ЭОД

5.1    Защита на уровне сообщений/пакетов (встроенная защита сообщений и пакетов)

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

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

В данном подразделе представлена структура системы защиты EDIFACT на уровне сообщений/пакетов.

Службы защиты, рассмотренные в настоящем стандарте, должны предоставляться применительно к любому существующему сообщению путем включения групп сегментов заголовка защиты и групп сегментов окончания защиты после сегмента UNH и перед сегментом UNT, а применительно к любому существующему пакету – путем включения указанных групп сегментов после сегмента UNO и перед сегментом UNP.

2

ГОСТРИСО 9735-5 -2012

5.1.2 Группы сегментов заголовка и окончания защиты

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

Рисунок 1 – Схематическое представление обмена, показывающее службы с защитой на уровне сообщений

На рисунке 2 приведено схематическое представление обмена, иллюстрирующее защиту на уровне пакетов.

Рисунок 2 – Схематическое представление обмена, показывающее службу с защитой на уровне пакетов

3

ГОСТ Р ИСО 9735-5 – 2012

5.1.3 Структура групп сегментов заголовка и окончания защиты

S

R

м

1

с

99

——–+

м

1

I

с

3

I

с

2

—-+ I

м

1

I I

с

3

I I

с

1

——–+

Таблица 1- Группы сегментов заголовка защиты и окончания защиты (служба защиты на уровне сообщений)

ТЕГ    Наименование

UNH    Заголовок сообщения

—–    Группа сегментов    1

USH    Заголовок защиты

USA    Алгоритм защиты

—–    Группа сегментов    2

USC    Сертификат

USA    Алгоритм защиты

USR    Результат защиты

С

99

—-+

м

1

I

с

1

—-+

м

1

Тело сообщения

—–    Группа сегментов    п

UST    Окончание защиты

USR    Результат защиты

UNT    Окончание сообщения

S

R

м

1

с

99

—+

м

1

I

с

3

I

с

2

—-+

I

м

1

I

I

с

3

I

I

с

1

—+

Таблица 2 – Группы сегментов заголовка защиты и окончания защиты (служба защиты на уровне пакетов)

ТЕГ    Наименование

UNO    Заголовок объекта

—–    Группа сегментов    1

USH    Заголовок защиты

USA    Алгоритм защиты

—–    Группа сегментов    2

USC    Сертификат

USA    Алгоритм защиты

USR    Результат защиты

С

99

—-+

м

1

I

с

1

—-+

м

1

Объект

—–    Группа сегментов    п

UST    Окончание защиты

USR    Результат защиты

UNP    Окончание объекта

Примечание – Полное описание сегментов и элементов данных, включая сегменты заголовка сообщения UNH, окончания сообщения UNT, заголовка объекта UNO и окончания объекта UNP приведено в ИСО 9735-10. В настоящем стандарте они не детализируются.

5.1.4 Детализация сегмента данных

Группа сегментов 1: USH-USA-SG2 (группа сегментов заголовка защиты)

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

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

ГОСТ Р ИСО 9735-5 – 2012

USH – заголовок защиты

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

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

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

–    при использовании симметричных алгоритмов или

–    при использовании асимметричных алгоритмов, когда имеются два сертификата; элемент S500 в этой ситуации позволяет различать сертификаты отправителя и адресата.

В последнем случае идентификатор участвующей стороны в элементе S500 (которым может быть любой из элементов данных S500/0511, S500/0513, S500/0515, S500/0586) должен быть тем же, что и идентификатор стороны, определенной как «владелец сертификата» в одном из элементов S500, присутствующих в составе сегмента USC из группы сегментов 2, а элемент данных S500/0577 должен указывать функцию участвующей стороны (отправитель или адресат).

Элемент данных «имя ключа» в составном элементе данных для идентификации службы защиты (S500/0538) может использоваться для установления зависимости между ключами отправляющей и принимающей сторон.

Эта зависимость может быть установлена с помощью простого элемента данных идентификатора ключа длясоставного элемента данных параметра алгоритма защиты (S503/0554) в сегменте USA группы сегментов 1.

Элемент данных S500/0538 в сегменте USH может использоваться в тех случаях, когда нет необходимости передавать сегмент USA в группе сегментов 1 (поскольку криптографические механизмы были предварительно согласованы между партнерами).

Рекомендуется использовать либо элемент данных S500/0538 в сегменте USH, либо элемент данных S503/0554 с надлежащим квалификатором в сегменте USA, но не оба этих элемента данных вместе в рамках одной и той же группы сегментов заголовка.

Сегмент USH может определять функцию фильтрации, используемую применительно к двоичным полям сегмента USA внутри группы сегментов 1 и сегмента USR соответствующей группы сегментов окончания защиты.

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

Сегмент USA – алгоритм защиты

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

Асимметричные алгоритмы не следует вызывать непосредственно в этом сегменте USA группы сегментов 1; они могут присутствовать только внутри группы сегментов 2, инициируемой сегментом USC.

Допускается использовать три вхождения сегмента USA. Одно вхождение следует использовать для симметричного алгоритма или хеш-функции, которые требуются для реализации службы защиты, определенной в сегменте USH. Описание двух других вхождений приведены в ИСО 9735-7.

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

Группа сегментов 2: USC-USA-USR (группа сертификата)

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

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

ГОСТ Р ИСО 9735-5 – 2012

В случаях, когда принимают решение использовать сертификат, не относящийся к EDIFACT (например, Х.509), его синтаксис и версия подлежат идентификации в элементе данных 0545 сегмента USC. Подобные сертификаты могут быть переданы в составе пакета EDIFACT.

Допускаются два вхождения группы сегментов USC-USA-USR. Одно вхождение имеет отношение к сертификату отправителя сообщения/пакета (этот сертификат будет использован получателем сообщения/пакета для проверки цифровой подписи отправителя); второе вхождение имеет отношение к сертификату получателя сообщения/пакета (запрашиваемому только по указателю сертификата), когда в целях сохранения конфиденциальности симметричных ключей отправитель использует открытый ключ получателя.

При наличии обоих вхо>кдений в рамках одной группы сегментов заголовка защиты их различение обеспечивается составным элементом данных идентификационных элементов защиты (S500) совместно с элементом данных указателя сертификата (0536).

Данную группу сегментов не применяют, если асимметричный алгоритм не используется.

Сегмент сертификата USC

Сегмент, содержащий удостоверение владельца сертификата и идентифицирует орган сертификации, выдавший этот сертификат. Элемент данных, называемый функцией фильтрации (код 0505) должен указывать конкретную функцию фильтрации, применяемую к двоичным полям сегментов USA и сегмента USR внутри группы сегментов 2.

Сертификат USC может иметь два вхождения S500: одно – для владельца сертификата (идентифицирующее сторону, которая подписывается закрытым ключом, ассоциируемым с открытым ключом, содержащимся в данном сертификате), и второе – для идентификации издателя сертификата (органа сертификации).

Сегмент USA – алгоритм защиты

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

1    алгоритм, использованный издателем сертификата при вычислении значения хеш-функции сертификата (функция хеширования);

2    алгоритм, использованный издателем сертификата для его изготовления (то есть для подписания результата применения хеш-функции к содержимому сертификата) (асимметричный алгоритм);

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

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

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

Сегмент USR – результат защиты

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

Применительно к сертификату, формирование электронной подписи начинается с обработки первого знака сегмента USC (буквы “U”) и заканчивается обработкой последнего знака последнего сегмента USA (включая следующий за ним разделитель).

Группа сегментов n: UST-USR (группа окончания защиты)

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

Сегмент UST – окончание защиты

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

Сегмент USR – результат защиты

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

6

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

2 Соответствие стандарту

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

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

5 Правила использования групп сегментов заголовка и окончания защиты для пакетного ЭОД

6 Правила использования групп сегментов заголовка и окончания защиты обмена и группы для пакетного ЭОД

Приложение А (справочное) Угрозы безопасности EDIFACT и технические решения проблемы

Приложение В (справочное) Способы защиты структуры EDIFACT

Приложение С (справочное) Примеры защиты сообщений

Приложение D (справочное) Функции фильтрации для наборов графических знаков UN/EDIFACT уровней А и С

Приложение Е (справочное) Службы и алгоритмы защиты

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

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

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30
Николай Иванов

Эксперт по стандартизации и метрологии! Разрешительная и нормативная документация.

Оцените автора
Все-ГОСТЫ РУ
Добавить комментарий

ГОСТ Р ИСО 9735-5-2012

ГОСТР

исо

9735-5-

2012

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

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT)

Синтаксические правила для прикладного уровня (версия 4, редакция 1)

Часть 5

Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника)

ISO 9735-5:2002

Electronic data interchange for administration, commerce and transport (EDIFACT) —

Application level syntax rules (Syntax version number: 4, Syntax release number: 1) —

Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of

origin)

(IDT)

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

Москва

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

2014

Предисловие

1    ПОДГОТОВЛЕН ЗАО «Проспект» совместно с Ассоциацией автоматической идентификации «ЮНИСКАН/ГС1 РУС» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 55 «Терминология, элементы данных и документация в бизнес-процессах и электронной торговле»

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

4    Настоящий стандарт идентичен международному стандарту ИСО 9735-5:2002 «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 5. Правила защиты для пакетного ЭОД1} (аутентичность, целостность и неотказуемость источника)» (ISO 9735-5:2002 «Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin»).

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок – в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).

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

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

11 ЭОД- электронный обмен данными соответствует английскому EDI – electronic data interchange.

ГОСТРИСО 9735-5 -2012

–    результат, вычисленный путем прямой обработки сообщения/пакета по алгоритму, определенному в сегменте USA внутри группы сегментов 1 из группы заголовка защиты, или

–    результат, подтвержденный электронной подписью с помощью асимметричного алгоритма, который задан в сегменте USA внутри группы сегментов 2 из группы сегментов заголовка защиты, результат хеширования сообщения/пакета по алгоритму, определенному в сегменте USA внутри группы сегментов 1 из группы сегментов заголовка защиты.

5.1.5 Область защиты

Допускается использовать два варианта применения области защиты:

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

Отсчет знаков группы сегментов заголовка защиты следует начинать с его первого знака (от буквы “U”) и заканчивать разделителем включительно, следующим за этой группой сегментов, а тело сообщения или объект – с первого знака после разделителя, завершающего последнюю группу сегментов заголовка защиты, до разделителя, предшествующего первому знаку первой группы сегментов окончания защиты, включительно.

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

Рисунок 3 иллюстрирует этот случай (область применения служб защиты, определенная в

и

N

Группа 3

Группа 2

Г руппа 1

ТЕЛО

Г руппа 1

Группа 2

Группа 3

Н/

сегментов

сегментов

сегментов

СООБЩЕ-

сегментов

сегментов

сегментов

и

заголовка

заголовка

заголовка

НИ Я/

окончания

окончания

окончания

N

О

защиты

защиты

защиты

ОБЪЕКТ

защиты

защиты

защиты

Рисунок 3 – Схематическое представление области защиты (только группа сегментов заголовка защиты и тело сообщения/объекта)

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

Рисунок 4 иллюстрирует этот случай (область применения служб защиты, определенной в заголовке защиты 2, выделена темно-серым цветом). ___

UN

Группа 3

Группа 2

Группа 1

ТЕЛО

Группа 1

Группа 2

Группа 3

и

N

Н/

сегментов

сегментов

сегментов

СООБЩЕ-

сегментов

сегментов

сегментов

Т/

UN

заголовка

заголовка

заголовка

НИ Я/

окончанияз

окончанияз

окончания

и

О

защиты

защиты

защиты

ОБЪЕКТ

ащиты

ащиты

защиты

N

Р

Рисунок 4 – Схематическое представление области защиты (от группы сегментов заголовка

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

защиты до группы сегментов окончания защиты)

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

В обоих случаях связь между группой сегментов заголовка защиты и соответствующей группой сегментов окончания защиты должна обеспечиваться элементами данных «справочный номер защиты» в сегментах USH и UST.

5.2 Принципы использования

5.2.1 Выбор служб защиты

Группа сегментов заголовка защиты может содержать в себе следующую общую информацию:

–    применяемые службы защиты;

–    идентификаторы взаимодействующих сторон;

7

ГОСТ Р ИСО 9735-5 – 2012

–    используемый механизм защиты;

–    уникальный идентификатор (порядковый номер и/или отметка времени);

–    требование неотказуемости приема.

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

5.2.2    Аутентичность

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

Служба защиты аутентификации источника должна быть определена в сегменте USH, а алгоритм – в сегменте USA группы сегментов 1; алгоритм должен быть симметричным.

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

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

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

5.2.3    Целостность

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

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

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

Эта служба может рассматриваться как промежуточный результат-службы аутентификации источника или службы неотказуемости источника.

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

5.2.4    Неотказуемость источника

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

Служба защиты, обеспечивающая неотказуемость источника, должна быть определена в сегменте USH, алгоритм хеширования – в сегменте USA группы сегментов 1, а асимметричный алгоритм электронной подписи – в сегментах USA группы сегментов 2, при использовании сертификатов.

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

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

Рассмотренная служба должна обеспечить также целостность контента и аутентификацию источника.

5.3 Внутреннее представление информации и фильтры для обеспечения соответствия синтаксическим правилам EDIFACT

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

8

ГОСТРИСО 9735-5 -2012

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

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

6 Правила использования групп сегментов заголовка и окончания защиты обмена и группы для пакетного ЭОД

6.1    Защита на уровнях групп и обменов (комплексная защита сообщений)

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

Методы защиты, рассмотренные в предыдущем разделе применительно к сообщениям/пакетам, могут также использоваться применительно к обменам и группам.

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

Если защита применяется на уровне сообщения/пакета, защищаемой структурой является тело сообщения или объект. На уровне групп защищаемой структурой является набор сообщений/пакетов внутри группы, включая все заголовки и окончания сообщений/пакетов. На уровне обмена объектом защиты является совокупность сообщений/пакетов или групп в рамках обмена, включая все заголовки и окончания сообщений/пакетов или групп.

6.2    Группы сегментов заголовка и окончания защиты

На рисунке 5 приведена схема обмена, при которой обеспечена защита как на уровне обмена, так и на уровне групп.

Рисунок 5 – Схематическое представление обмена, обеспечивающее защиту как на уровне обмена,так и на уровне групп

9

ГОСТ Р ИСО 9735-5 – 2012

6.3 Структура, образуемая группами сегментов заголовка и окончания защиты

S

R

м

1

с

99

м

1

I

с

3

I

с

2

—-+

I

м

1

I

I

с

3

I

I

с

1

—+

ТЕГ

Наименование

UNB

Заголовок обмена

Группа сегментов

1

USH

Заголовок защиты

USA

Алгоритм защиты

Группа сегментов

2

use

Сертификат

USA

Алгоритм защиты

USR

Результат защиты

Группа (группы) или

сообщение (сообщения)/пакет (пакеты)

Группа сегментов п

——- С

99

—-+

UST

Окончание защиты

М

1

I

USR

Результат защиты

С

1

—-+

UNZ

Окончание обмена

М

1

Таблица 4 – Группы сегментов заголовка и окончания защиты (безопасность только на уровне группы)

Наименование

S

R

Заголовок группы

м

1

-|—1-_ . _ “1

Q Q

1 руппа. сегментов i

у z>

Заголовок защиты

м

i

I

Алгоритм защиты

с

3

I

Группа сегментов 2 ———

—– с

2

—-+

I

Сертификат

м

1

I

I

Алгоритм защиты

с

3

I

I

Результат защиты

с

1

— +

Сообщение (сообщения)/пакет

(пакеты)

Группа сегментов п ———

—– С

99

—-+

Окончание защиты

М

1

I

Результат защиты

С

1

—-+

Окончание группы

М

1

Таблица 3 – Группы сегментов заголовка и окончания защиты (безопасность только на уровне обмена)

ТЕГ

UNG

USH

USA

USC

USA

USR

UST

USR

UNE

Примечание – Полное описание спецификаций сегментов и элементов данных, включая сегменты заголовка обмена UNB, окончания обмена UNZ, заголовка группы UNG и окончания группы UNE приведено в ИСО 9735-10. В настоящем стандарте они не детализируются.

6.4 Область защиты

Допускается использовать два варианта применения области защиты:

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

Отсчет знаков группы сегментов заголовка защиты следует начинать с первого знака (с буквы “U”) и заканчивать разделителем включительно, следующим за этой группой сегментов, а группа(группы) или сообщение(ия) /пакет(пакеты) – с первого знака после разделителя,

ГОСТ Р ИСО 9735-5 – 2012

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

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

Рисунки 6 и 7 иллюстрируют этот случай (область применения службы защиты, определенная в заголовке защиты 2, выделена темно-серым цветом)._

и

N

В

Группа 3 сегментов

Группа 2 сегмент ов

Группа 1 сегментов

ГРУППА

(ГРУППЫ)

ИЛИ

СООБЩЕНИЕ

(СООБЩЕНИЯ)/

ПАКЕТ

(ПАКЕТЫ)

Группа 1 сегментов

Группа 2 сегментов

Группа 3 сегментов

и

заголовка

заголовк

заголовка

окончанияз

окончания

окончания

NZ

защиты

а

защиты

защиты

ащиты

защиты

защиты

Рисунок 6 – Схематическое представление области защиты: только группа сегментов заголовка защиты и группа (группы) или сообщение(ия) / пакет (пакеты)_

1 1

Группа 3 сегментов заголовка защиты

Группа 2 сегментовза головка защиты

Группа 1 сегменто в

заголовка

защиты

СООБЩЕНИЕ (СООБЩЕНИЯ)/П АКЕТ (ПАКЕТЫ)

Группа 1 сегментов окончания защиты

Группа 2 сегменто вокончан иязащит ы

Группа 3 сегменто вокончан иязащиты

и

N

Е

Рисунок 7 – Схематическое представление области защиты: только группа сегментов заголовка защиты и сообщение(ия) / пакет (пакеты)

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

Эта область должна включать в себя каждый знак – от первой буквы “U” текущей группы сегментов заголовка защиты до разделителя, предшествующего первому знаку соответствующей группы сегментов окончания защиты, включительно.

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

и

N

В

Группа 3 сегментов заголовка

защиты

Группа 2 сегментов заголовка защиты

Г руппа 1 сегментов заголовка защиты

ГРУППА (ГРУППЫ) ИЛИ СООБЩЕНИЕ (СООБЩЕН ИЯ)/ПА КЕТ(ПАКЕТЫ)

Г руппа 1 сегментов окончанияза щиты

Г руппа 2 сегментов окончанияза щиты

Г руппа 3 сегментов окончанияз ащиты

Рисунок 8 – Схематическое представление области защиты (от группы сегментов заголовка защиты до группы сегментов окончания защиты)_

Г руппа 3 сегментов заголовка защиты

Г руппа 2 сегментов заголовка защиты

Г руппа 1 сегментов заголовка защиты

СООБЩЕНИЕ (СООБЩЕН ИЯ )/ПАК ЕТ(Ы)

Г руппа 1 сегментов окончанияз ащиты

Г руппа 2 сегментов окончанияз ащиты

Г руппа 3 сегментов окончанияз ащиты

Рисунок 9 – Схематическое представление области защиты (от группы сегментов заголовка защиты до группы сегментов окончания защиты)

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

В обоих случаях связь между группой сегментов заголовка защиты и соответствующей группой сегментов окончания защиты должна обеспечиваться элементами данных «справочный номер защиты» в сегментах USH и UST.

11

Приложение А (справочное)

Угрозы безопасности EDIFACT и технические решения проблемы

А.1 Введение

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

А.2 Угрозы безопасности

Хранение и передача сообщений/пакетов EDIFACT в электронной среде подвержены целому ряду угроз, к числу которых относятся:

–    несанкционированное раскрытие информации, содержащейся в сообщениях и пакетах;

–    умышленное внедрение посторонних сообщений/пакетов;

–    копирование, утеря или воспроизведение сообщений/пакетов;

–    внесение изменений в содержимое сообщения/пакета;

–    уничтожение сообщений/пакетов;

–    отрицание отправителем или получателем сообщения/пакета факта его передачи или приема.

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

А.З Защитные решения — основные службы и принципы их использования

А.3.1 Общие положения

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

Прежде всего, важно однозначно идентифицировать взаимодействующие стороны, вовлеченные в обеспечение защиты сообщений/пакетов: инициатора защиты (далее – отправитель), который перед передачей сообщения/пакета осуществляет его защиту, и адресата защиты (далее -получатель), который выполняет проверку полученного сообщения/пакета. Эти стороны могут быть идентифицированы в сегментах защиты. При применении асимметричных алгоритмов защиты такая идентификация может быть реализована путем использования так называемых «сертификатов» (в действительности это может быть либо сам сертификат, либо его учетный номер), описание которых приведено ниже.

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

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

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

Требования и методы, предназначенные для защиты сообщений/пакетов, групп или обменов EDIFACT, приведены ниже.

А.З.2 Целостность цепочки

Целостность цепочки обеспечивает защиту от копирования, дополнения, изъятия, потери или воспроизведения структуры EDIFACT (сообщения/пакета, группы или обмена).

Для обнаружения потери сообщений/пакетов, групп или обменов:

–    отправитель может включить, а получатель проверить порядковый номер (относящийся к потоку сообщений/пакетов мехщу двумя участвующими сторонами);

–    отправитель может запросить подтверждение приема (квитирование) и проверить его правильность.

12

ГОСТ Р ИСО 9735-5 – 2012

Для обнаружения добавленных или дублированных сообщений/пакетов, групп или обменов:

–    отправитель может включить, а получатель проверить порядковый номер;

–    отправитель может включить, а получатель проверить отметку времени.

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

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

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

А.3.3 Целостность информационного содержимого

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

Защита может быть обеспечена отправителем посредством введения контрольного параметра целостности. Значение этого параметра вычисляют с помощью надлежащего криптографического алгоритма, в частности такого, как MDC [ModificationDetectionCode (код для обнаружения изменений)]. Так как это контрольное значение само по себе не защищено, к нему должны применяться дополнительные меры защиты, такие как пересылка контрольного значения по отдельному каналу или вычисление цифровой подписи с целью получения гарантии неотказуемости источника. Как вариант, на целостность содержимого может влиять аутентификация отправителя, выполняемая с использованием кода аутентификации сообщения. В этом случае получатель с помощью соответствующих алгоритмов и параметров вычисляет контрольное значение параметра целостности реально принятых данных и сравнивает результат вычисления с полученным контрольным значением.

В рамках ЭОД обеспечение целостности содержимого обычно является производным результатом аутентификации источника или неотказуемости источника.

А.3.4 Аутентификация источника

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

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

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

В большинстве случаев рекомендуется иметь хотя бы службу аутентификации источника.

А.3.5 Неотказуемость источника

Неотказуемость источника защищает получателя сообщения/пакета, группы или обмена от отказа отправителя от факта посылки этих структур.

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

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

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

А.3.6 Неотказуемость приема

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

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

13

ГОСТ Р ИСО 9735-5 – 2012

А.3.7 Конфиденциальность содержимого

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

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

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

Требования к службе конфиденциальности установлены в ИСО 9735-7.

А.3.8 Взаимосвязь служб защиты

сохранению целостности контента. Взаимосвязи служб приведены в таблице А.1. Таблица А.1—Взаимосвязь служб_

Служба защиты

влечет за собой также обеспечение

целостности содержимого

аутентификации источника

неотказуемости

источника

Целостность

содержимого

Да

Аутентификация

источника

Да

Да

Неотказуемость

источника

Да

Да

Да

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

14

ГОСТ Р ИСО 9735-5 – 2012

Приложение В (справочное)

Способы защиты структуры EDI FACT

В.1 Общие положения

В данном приложении описаны некоторые из основополагающих этапов обеспечения безопасности структур EDIFACT: сообщений/пакетов, групп и обменов. Подробное описание и объяснение принципов защиты приведено в приложении А настоящего стандарта, а также в ИСО 7498-2, ИСО/МЭК 9594-8 и в документе CCITT Х.509.

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

–    целостность содержимого,

–    аутентификация источника и

–    неотказуемость источника.

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

Такие взаимосвязи указаны в таблице А.1 приложения А. С учетом приведенных в ней взаимосвязей отправитель должен выбрать не более одной из трех указанных служб.

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

В.2 Двустороннее соглашение об обмене или привлечение третьей стороны

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

Минимальным требованием должно быть заключение с каждым из партнеров отдельного двустороннего соглашения об использовании служб защиты, конкретных алгоритмов, кодов, методов управления ключами, действий в случае ненадлежащего поведения и т. п. Образец подобного соглашения доступен в рамках программы TEDIS Европейской комиссии. При таком подходе в сообщение/пакет должен быть включен небольшой объем информации, касающейся обеспечения защиты.

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

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

В.З Практические аспекты

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

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

В.4 Процедура конструирования защищенной структуры EDIFACT

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

15

ГОСТ Р ИСО 9735-5 – 2012

лица, имеющие закрытые ключи. Делать это сразу после создания структуры EDIFACT не обязательно.

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

В.5 Последовательность применения служб защиты

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

В.6 Защита отдельным сообщением на уровне сообщений/пакетов

В.6.1 Требования бизнеса

Существуют два следующих требования бизнеса к данной функциональной возможности:

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

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

Эти требования могут быть выполнены путем использования сообщения для защищенной аутентификации и защищенного квитирования AUTACK, подробно описанного в ИСО 9735-6.

В.6.2 Защита отдельным сообщением, используемая отправителем

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

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

В.6.3 Защита отдельным сообщением, используемая получателем

Такое использование сообщения AUTACK ориентировано на обеспечение неотказуемости приема. Подробное описание сообщения AUTACK приведено в ИСО 9735-6.

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

В.7 Защита отдельным сообщением на уровнях групп или обменов

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

Существуют два требования бизнеса к данной функциональной возможности:

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

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

Эти требования могут быть выполнены путем использования сообщения защищенной аутентификации и защищенного квитирования AUTACK, подробно описанного в ИСО 9735-6.

16

ГОСТ Р ИСО 9735-5 – 2012

Содержание

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

2    Соответствие стандарту………………………………………………………………………………….. 1

3    Нормативные ссылки……………………………………………………………………………………………………… 1

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

5    Правила использования групп сегментов заголовка и окончания защиты

для пакетного ЭОД…………………………………………………………………………………………………………. 2

6    Правила использования групп сегментов заголовка и окончания защиты обмена и группы

для пакетного ЭОД……………………………………………………………………………………………………………. 9

Приложение А (справочное) Угрозы безопасности EDIFACT и

технические решения проблемы………………………………………………………………… 12

Приложение В (справочное) Способы защиты структуры EDIFACT……………………………………. 15

Приложение С (справочное) Примеры защиты сообщений………………………………………………… 17

Приложение D (справочное) Функции фильтрации для наборов графических

знаков UN/EDIFACT уровней А и С……………………………………………………………… 26

Приложение Е (справочное)    Службы и алгоритмы защиты……………………………………………….. 28

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

международных стандартов ссылочным национальным

стандартам Российской Федерации…………………………………………………. 35

Библиография…………………………………………………………………………………………………………………… 36

ГОСТ Р ИСО 9735-5 – 2012

Приложение С (справочное) Примеры защиты сообщений

С.1 Введение

В данном приложении приведены три примера применений служебных сегментов защиты.

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

Пример 1. Аутентификация источника сообщения

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

Пример 2. Неотказуемость источника (первый метод)

Данный пример показывает, как служебные сегменты защиты могут использоваться в случае применения асимметричного алгоритма защиты для обеспечения неотказуемости источника. Алгоритмом, применяемым непосредственно к передаваемому сообщению является функция хеширования, которая не требует предварительного обмена ключами между партнерами. Значение хеш-функции подписывается с использованием ассиметричного алгоритма. Открытый ключ, необходимый получателю для проверки подписи в сообщении, включают в сегмент сертификата, который передается в группе сегментов заголовка защиты сообщения. Этот сертификат должен быть подписан его издателем («органом сертификации») и должен содержать открытый ключ органа сертификации для предоставления любому из партнеров возможности проверить целостность и подлинность сертификата.

Пример 3. Неотказуемость источника (второй метод)

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

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

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

Данный метод используют банки Франции в рамках системы ЕТЕВАС 5 (защищенная система передачи файлов между банками и корпоративными клиентами).

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

С.2 Пример 1. Аутентификация источника сообщения

С.2.1 Краткое описание

Компания А поручает Банку А (код 603000) списать с ее счета №00387806 сумму 54345,10 фунтов стерлингов 9 апреля 1996 г. Эта сумма должна быть переведена в Банк В (код 201827) на счет № 00663151 Компании В, находящейся по адресу WestDock, MilfordHaven. Платеж производится на основании выставленного счета № 62345. Контактное лицо получателя платежа – м-р Джонс, отдел продаж.

Банк А требует, чтобы платежное поручение было защищено функцией защиты «аутентификация источника сообщения», которая осуществляется путем генерирования отправителем сообщения так называемого «кода аутентификации сообщения» (MAC) с помощью

17

Введение

Настоящий стандарт включает в себя правила прикладного уровня для структурирования данных в рамках обмена электронными сообщениями в открытой среде, с учетом требований пакетной или интерактивной обработки. Эти правила утверждены Европейской экономической комиссией Организации Объединенных Наций (UN/ECE) в качестве синтаксических правил электронного обмена данными в управлении, торговле и на транспорте (EDIFACT) и являются частью «Справочника по обмену торговыми данными Организации Объединенных Наций» (UNTDID1*), который содержит также рекомендации по разработке сообщений пакетного и интерактивного обмена.

Спецификации и протоколы связи не входят в область распространения настоящего стандарта.

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

Комплекс стандартов ИСО 9735 состоит из следующих частей, имеющих общий подзаголовок «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1)»:

—    часть 1. Синтаксические правила, общие для всех частей;

—    часть 2. Синтаксические правила, специфичные для пакетного ЭОД;

—    часть 3. Синтаксические правила, специфичные для интерактивного ЭОД;

—    часть 4. Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения — CONTRL);

—    часть 5. Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника);

—    часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения — AUTACK);

—    часть 7. Правила защиты для пакетного ЭОД (конфиденциальность);

—    часть 8. Ассоциированные данные в ЭОД;

—    часть 9. Сообщение для управления ключами и сертификатами защиты (тип сообщения — KEYMAN);

—    часть 10. Справочники служебных синтаксических структур.

11 UNTDID – United Nations Trade Data Interchange Directory. IV

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

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT) Синтаксические правила для прикладного уровня (версия 4, редакция 1)

Часть 5

Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника)

Electronic data interchange for administration, commerce and transport (EDIFACT) —

Application level syntax rules (Syntax version number: 4, Syntax release number: 1) —

Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)

Дата введения – 2014-01-01

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

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

2    Соответствие стандарту

Для соответствия обмена настоящему стандарту в обязательном элементе данных 0002 (номер версии синтаксических правил) следует использовать номер версии “4”, а в условном элементе данных 0076 (номер редакции синтаксических правил) должен быть указан номер редакции “01”. Каждый из этих элементов данных входит в сегмент UNB (заголовок обмена). В обменах, в которых продолжает использоваться синтаксис более ранних версий, для различения соответствующих синтаксических правил, необходимо указывать следующие номера версий:

ИСО 9735:1988 – номер версии синтаксических правил: 1;

ИСО 9735:1988 (с изменениями, принятыми в 1990 г.) – номер версии синтаксических правил:2;

ИСО 9735:1988 (с изменением 1, принятым в 1992 г.) – номер версии синтаксических правил: 3;

ИСО 9735:1998 – номер версии синтаксических правил: 4.

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

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

Устройства, поддерживающие настоящий стандарт, признаются соответствующими ему, если эти устройства способны формировать и/или интерпретировать данные, структурированные и представленные в соответствии с требованиями настоящего стандарта.

Соответствие настоящему стандарту включает в себя также соответствие частям 1, 2, 8 и 10 комплекса стандартов ИСО 9735.

Положения стандартов, указанных в настоящем стандарте, являются составными элементами критериев соответствия настоящему стандарту.

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

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

ИСО 9735-1:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 1.

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

ГОСТ Р ИСО 9735-5 – 2012

Синтаксические правила, общие для всех частей (ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules common to all parts)

ИСО 9735-2:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 2. Синтаксические правила, специфичные для пакетного ЭОД (ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific to batch EDI)

ИСО 9735-6:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения — AUTACK) (ISO 9735-6:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 6: Secure authentication and acknowledgement message (message type — AUTACK))

ИСО 9735-7:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 7. Правила защиты для пакетного ЭОД (конфиденциальность) (ISO 9735-7:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 7: Security rules for batch EDI (confidentiality))

ИСО 9735-8:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 8. Ассоциированные данные в ЭОД (ISO 9735-8:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 8: Associated data in EDI)

ИСО 9735-10:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 10. Справочники служебных синтаксических структур (ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 10: Syntax service directories)

ИСО/МЭК 10181-2:1996 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы аутентификации (ISO/IEC 10181-2:1996 Information technology — Open Systems Interconnection — Security frameworks for open systems: Authentication framework)

ИСО/МЭК 10181-4:1997 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы неотказуемости (ISO/IEC 10181-4:1997, Information technology — Open Systems Interconnection — Security frameworks for open systems: Nonrepudiation framework)

ИСО/МЭК 10181-6:1996 Информационные технологии. Взаимодействие открытых систем. Основы безопасности для открытых систем. Основы целостности (ISO/IEC 10181-6:1996, Information technology — Open Systems Interconnection — Security frameworks for open systems: Integrity framework)

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

В настоящем стандарте применены термины, определенные в ИСО 9735-1.

5    Правила использования групп сегментов заголовка и окончания защиты для пакетного ЭОД

5.1    Защита на уровне сообщений/пакетов (встроенная защита сообщений и пакетов)

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

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

В данном подразделе представлена структура системы защиты EDIFACT на уровне сообщений/пакетов.

Службы защиты, рассмотренные в настоящем стандарте, должны предоставляться применительно к любому существующему сообщению путем включения групп сегментов заголовка защиты и групп сегментов окончания защиты после сегмента UNH и перед сегментом UNT, а применительно к любому существующему пакету – путем включения указанных групп сегментов после сегмента UNO и перед сегментом UNP.

2

ГОСТРИСО 9735-5 -2012

5.1.2 Группы сегментов заголовка и окончания защиты

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

Рисунок 1 – Схематическое представление обмена, показывающее службы с защитой на уровне сообщений

На рисунке 2 приведено схематическое представление обмена, иллюстрирующее защиту на уровне пакетов.

Рисунок 2 – Схематическое представление обмена, показывающее службу с защитой на уровне пакетов

3

ГОСТ Р ИСО 9735-5 – 2012

5.1.3 Структура групп сегментов заголовка и окончания защиты

S

R

м

1

с

99

——–+

м

1

I

с

3

I

с

2

—-+ I

м

1

I I

с

3

I I

с

1

——–+

Таблица 1- Группы сегментов заголовка защиты и окончания защиты (служба защиты на уровне сообщений)

ТЕГ    Наименование

UNH    Заголовок сообщения

—–    Группа сегментов    1

USH    Заголовок защиты

USA    Алгоритм защиты

—–    Группа сегментов    2

USC    Сертификат

USA    Алгоритм защиты

USR    Результат защиты

С

99

—-+

м

1

I

с

1

—-+

м

1

Тело сообщения

—–    Группа сегментов    п

UST    Окончание защиты

USR    Результат защиты

UNT    Окончание сообщения

S

R

м

1

с

99

—+

м

1

I

с

3

I

с

2

—-+

I

м

1

I

I

с

3

I

I

с

1

—+

Таблица 2 – Группы сегментов заголовка защиты и окончания защиты (служба защиты на уровне пакетов)

ТЕГ    Наименование

UNO    Заголовок объекта

—–    Группа сегментов    1

USH    Заголовок защиты

USA    Алгоритм защиты

—–    Группа сегментов    2

USC    Сертификат

USA    Алгоритм защиты

USR    Результат защиты

С

99

—-+

м

1

I

с

1

—-+

м

1

Объект

—–    Группа сегментов    п

UST    Окончание защиты

USR    Результат защиты

UNP    Окончание объекта

Примечание – Полное описание сегментов и элементов данных, включая сегменты заголовка сообщения UNH, окончания сообщения UNT, заголовка объекта UNO и окончания объекта UNP приведено в ИСО 9735-10. В настоящем стандарте они не детализируются.

5.1.4 Детализация сегмента данных

Группа сегментов 1: USH-USA-SG2 (группа сегментов заголовка защиты)

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

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

ГОСТ Р ИСО 9735-5 – 2012

USH – заголовок защиты

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

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

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

–    при использовании симметричных алгоритмов или

–    при использовании асимметричных алгоритмов, когда имеются два сертификата; элемент S500 в этой ситуации позволяет различать сертификаты отправителя и адресата.

В последнем случае идентификатор участвующей стороны в элементе S500 (которым может быть любой из элементов данных S500/0511, S500/0513, S500/0515, S500/0586) должен быть тем же, что и идентификатор стороны, определенной как «владелец сертификата» в одном из элементов S500, присутствующих в составе сегмента USC из группы сегментов 2, а элемент данных S500/0577 должен указывать функцию участвующей стороны (отправитель или адресат).

Элемент данных «имя ключа» в составном элементе данных для идентификации службы защиты (S500/0538) может использоваться для установления зависимости между ключами отправляющей и принимающей сторон.

Эта зависимость может быть установлена с помощью простого элемента данных идентификатора ключа длясоставного элемента данных параметра алгоритма защиты (S503/0554) в сегменте USA группы сегментов 1.

Элемент данных S500/0538 в сегменте USH может использоваться в тех случаях, когда нет необходимости передавать сегмент USA в группе сегментов 1 (поскольку криптографические механизмы были предварительно согласованы между партнерами).

Рекомендуется использовать либо элемент данных S500/0538 в сегменте USH, либо элемент данных S503/0554 с надлежащим квалификатором в сегменте USA, но не оба этих элемента данных вместе в рамках одной и той же группы сегментов заголовка.

Сегмент USH может определять функцию фильтрации, используемую применительно к двоичным полям сегмента USA внутри группы сегментов 1 и сегмента USR соответствующей группы сегментов окончания защиты.

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

Сегмент USA – алгоритм защиты

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

Асимметричные алгоритмы не следует вызывать непосредственно в этом сегменте USA группы сегментов 1; они могут присутствовать только внутри группы сегментов 2, инициируемой сегментом USC.

Допускается использовать три вхождения сегмента USA. Одно вхождение следует использовать для симметричного алгоритма или хеш-функции, которые требуются для реализации службы защиты, определенной в сегменте USH. Описание двух других вхождений приведены в ИСО 9735-7.

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

Группа сегментов 2: USC-USA-USR (группа сертификата)

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

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

ГОСТ Р ИСО 9735-5 – 2012

В случаях, когда принимают решение использовать сертификат, не относящийся к EDIFACT (например, Х.509), его синтаксис и версия подлежат идентификации в элементе данных 0545 сегмента USC. Подобные сертификаты могут быть переданы в составе пакета EDIFACT.

Допускаются два вхождения группы сегментов USC-USA-USR. Одно вхождение имеет отношение к сертификату отправителя сообщения/пакета (этот сертификат будет использован получателем сообщения/пакета для проверки цифровой подписи отправителя); второе вхождение имеет отношение к сертификату получателя сообщения/пакета (запрашиваемому только по указателю сертификата), когда в целях сохранения конфиденциальности симметричных ключей отправитель использует открытый ключ получателя.

При наличии обоих вхо>кдений в рамках одной группы сегментов заголовка защиты их различение обеспечивается составным элементом данных идентификационных элементов защиты (S500) совместно с элементом данных указателя сертификата (0536).

Данную группу сегментов не применяют, если асимметричный алгоритм не используется.

Сегмент сертификата USC

Сегмент, содержащий удостоверение владельца сертификата и идентифицирует орган сертификации, выдавший этот сертификат. Элемент данных, называемый функцией фильтрации (код 0505) должен указывать конкретную функцию фильтрации, применяемую к двоичным полям сегментов USA и сегмента USR внутри группы сегментов 2.

Сертификат USC может иметь два вхождения S500: одно – для владельца сертификата (идентифицирующее сторону, которая подписывается закрытым ключом, ассоциируемым с открытым ключом, содержащимся в данном сертификате), и второе – для идентификации издателя сертификата (органа сертификации).

Сегмент USA – алгоритм защиты

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

1    алгоритм, использованный издателем сертификата при вычислении значения хеш-функции сертификата (функция хеширования);

2    алгоритм, использованный издателем сертификата для его изготовления (то есть для подписания результата применения хеш-функции к содержимому сертификата) (асимметричный алгоритм);

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

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

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

Сегмент USR – результат защиты

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

Применительно к сертификату, формирование электронной подписи начинается с обработки первого знака сегмента USC (буквы “U”) и заканчивается обработкой последнего знака последнего сегмента USA (включая следующий за ним разделитель).

Группа сегментов n: UST-USR (группа окончания защиты)

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

Сегмент UST – окончание защиты

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

Сегмент USR – результат защиты

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

6

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

2 Соответствие стандарту

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

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

5 Правила использования групп сегментов заголовка и окончания защиты для пакетного ЭОД

6 Правила использования групп сегментов заголовка и окончания защиты обмена и группы для пакетного ЭОД

Приложение А (справочное) Угрозы безопасности EDIFACT и технические решения проблемы

Приложение В (справочное) Способы защиты структуры EDIFACT

Приложение С (справочное) Примеры защиты сообщений

Приложение D (справочное) Функции фильтрации для наборов графических знаков UN/EDIFACT уровней А и С

Приложение Е (справочное) Службы и алгоритмы защиты

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

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

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30
Николай Иванов

Эксперт по стандартизации и метрологии! Разрешительная и нормативная документация.

Оцените автора
Все-ГОСТЫ РУ
Добавить комментарий