Национальный стандарт РФ ГОСТ Р ИСО/МЭК 19785-4-2012 "Информационные технологии. Биометрия. Единая структура форматов обмена биометрическими данными. Часть 4. Спецификация формата блока защиты информации" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2012 г. N 554-ст)

Information technology. Biometrics. Common Biometric Exchange Formats Framework. Part 4. Security block format specifications

Дата введения - 1 января 2013 г.

Введен впервые

ГАРАНТ:

Курсив в тексте не приводится

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 Подготовлен Ассоциацией автоматической идентификации "ЮНИСКАН/ГС1 РУС" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 355 "Технологии автоматической идентификации и сбора данных и биометрия"

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2012 г. N 554-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19785-4:2010 "Информационные технологии - Единая структура форматов обмена биометрическими данными - Часть 4: Спецификация формата блока защиты информации" (ISO/IEC 19785-4:2010 "Information technology - Common Biometric Exchange Formats Framework - Part 4: Security block format specifications").

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5).

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

5 Введен впервые

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

Введение

Комплекс стандартов ИСО/МЭК 19785 имеет общий заголовок "Информационные технологии. Единая структура форматов обмена биометрическими данными" и включает в себя следующие части:

- часть 1. Спецификация элементов данных;

- часть 2. Процедуры действий регистрационного органа в области биометрии;

- часть 3. Спецификации форматов ведущей организации;

- часть 4. Спецификация блока защиты информации.

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

Для обеспечения взаимодействия биометрических систем требования к единой структуре форматов обмена биометрическими данными (ЕСФОБД) установлены в ИСО/МЭК 19785-1 с целью ассоциирования дополнительных данных с одним или несколькими блоками биометрических данных (ББД). Блок защиты информации (БЗИ) обеспечивает защиту биометрических данных в соответствии с требованиями ИСО/МЭК 19785-1, но требования к содержанию и спецификации БЗИ в данном стандарте не установлены.

Если в формате ведущей организации не предусмотрено использование БЗИ, то в элементы данных CBEFF_BDB_encryption_options и CBEFF_BIR_integrity_options должны быть установлены значения NO ENCRYPTION и NO INTEGRITY соответственно.

Если в формате ведущей организации предусмотрено использование БЗИ, то может быть применен БЗИ, спецификация которого соответствует требованиям настоящего стандарта, или любой другой БЗИ. Кроме того, в элементах данных ЕСФОБД CBEFF_SB_format_owner и CBEFF_SB_format_type устанавливают значения, которые обеспечивают идентификацию используемого БЗИ.

Кроме БЗИ, требования к которым установлены в настоящем стандарте, допускается использовать БЗИ, предназначенные для конкретных целей. Например БЗИ, требования к которому установлены в ИСО/МЭК 24713-3 для документа МОТ*(1), удостоверяющего личность моряка.

В разделе 5 настоящего стандарта установлены требования к БЗИ общего применения, обеспечивающему возможность применения различных способов защиты информации с использованием шифрования и целостности, соответствующих RFC 3852 Cryptographic Message Syntax (CMS)*(2) с некоторыми отличающимися от установленных в данном документе требованиями к EnvelopedData, Encrypted Data, SignedData и AuthenticatedData*(3). Данные изменения введены с целью обеспечения соответствия требованиям к защите биометрической информации ЕСФОБД. В спецификации данного БЗИ предусмотрен также Authentication Context for Biometrics (ACBio)*(4), требования к которому установлены в ИСО/МЭК 24761. ACBio также основан на схеме синтаксиса криптографических сообщений, определенной в RFC 3852. Использование ACBio позволяет определить уровни безопасности систем, формирующих аутентифицированные биометрические данные. ACBio также необходим для обеспечения (TAI)*(5) [3].

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

Сноски в тексте стандарта, выделенные курсивом, приведены для пояснения текста оригинала.

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

Настоящий стандарт устанавливает требования к форматам БЗИ (по ИСО/МЭК 19785-1), зарегистрированным в соответствии с ИСО/МЭК 19785-2 в качестве форматов, определенных биометрической организацией ЕСФОБД ИСО/МЭК СТК1/ПК37, а также требования к порядку присвоения зарегистрированного идентификатора формата БЗИ.

Примечание - Идентификатор формата БЗИ записывают в стандартный биометрический заголовок (СБЗ) формата ведущей организации ЕСФОБД или указывают, что использование другого БЗИ неприемлемо.

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

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

Формат БЗИ, установленный в разделе 6 настоящего стандарта, является более ограниченным и простым, не предусматривает использования ACBio и шифрования ББД.

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

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

ИСО/МЭК 8824 (все части) Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН 1) (ISO/IEC 8824 (all parts), ITU-Т Rec. Х.680 - 683, Information technology - Abstract Syntax Notation One (ASN. 1))

ИСО/МЭК 8825 (все части) Информационные технологии. Правила кодирования АСН.1 (ISO/IEC 8825 (all parts), ITU-Т Rec. Х.690 - 693, Information technology - ASN.1 encoding rules)

ИСО/МЭК 9798-6 Информационные технологии. Методы защиты. Аутентификация объектов. Часть 6. Механизмы с применением ручной передачи данных (ISO/IEC 9798-6, Information technology - Security techniques - Entity authentication - Part 6: Mechanisms using manual data transfer)

ИСО/МЭК 19784-1 Информационные технологии. Биометрический программный интерфейс. Часть 1. Спецификация биометрического программного интерфейса (ISO/IEC 19784-1, Information technology - Biometric application programming interface - Part 1: BioAPI specification)

ИСО/МЭК 19785-1 Информационные технологии. Единая структура форматов обмена биометрическими данными. Часть 1. Спецификация элементов данных (ISO/IEC 19785-1, Information technology - Common Biometric Exchange Formats Framework - Part 1: Data element specification)

ИСО/МЭК 24761 Информационные технологии. Методы защиты информации. Аутентификационный статус для биометрии (ISO/IEC 24761, Information technology - Security techniques - Authentication context for biometrics)

RFC 3852 Криптографический синтаксис сообщений (RFC 3852, Cryptographic Message Syntax (CMS), July 2004)

RFC 5911 Новые модули ACH.1 для криптографического синтаксиса сообщений и криптографической защиты сообщений электронной почты (RFC 5911, New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S-MIME, June 2010)

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

3.1 Термины, определенные в ИСО/МЭК 19785-1

В настоящем стандарте применены следующие термины, определенные в ИСО/МЭК 19785-1:

биометрический (biometric);

биометрия (biometrics);

блок биометрических данных (ББД) (biometric data block (BDB));

запись биометрической информации (ЗБИ) (biometric information record (BIR));

организация-участник ЕСФОБД (CBEFF biometric organization);

блок защиты информации (БЗИ) (security block (SB));

формат блока защиты информации (security block format);

идентификатор формата блока защиты информации (security block format identifier);

владелец формата блока защиты информации (security block format owner);

стандартный биометрический заголовок (СБЗ) (standard biometric header (SBH)).

3.2 Термины, определенные в ИСО/МЭК 19784-1

В настоящем стандарте применен следующий термин, определенный в ИСО/МЭК 19784-1:

модуль БиоАПИ (BioAPI Unit).

3.3 Термины, определенные в ИСО/МЭК 24761

В настоящем стандарте применены следующие термины, определенные в ИСО/МЭК 24761:

отчет АСБио (ACBio instance);

аутентификационный статус для биометрии (АСБио) (authentication context for biometrics (ACBio));

модуль обработки биометрических данных (МОБД) (biometric processing unit (BPU)).

3.4 Термины, определенные в ИСО/МЭК 9798-6

В настоящем стандарте применен следующий термин, определенный в ИСО/МЭК 9798-6:

аутентификационный код сообщения (message authentication code).

4 Обозначения и сокращения

4.1 Обозначения и сокращения по ИСО/МЭК 19785-1

В настоящем стандарте применены следующие обозначения и сокращения по ИСО/МЭК 19785-1:

ББД (ВОВ);

3BH (BIR);

ЕСФОБД (CBEFF);

БЗИ (SB);

СБЗ (SBH).

4.2 Обозначения и сокращения по ИСО/МЭК 24761

В настоящем стандарте применены следующие обозначения и сокращения по ИСО/МЭК 24761:

АСБио (ACBio);

МОБД (ВРи).

4.3 Обозначения и сокращения по ИСО/МЭК 9798-6

В настоящем стандарте применено следующее обозначение по ИСО/МЭК 9798-6:

АКС (MAC).

4.4 Обозначения и сокращения по RFC 3852

В настоящем стандарте применено следующее обозначение по RFC 3852:

COC*(6) (CRL).

5 Формат блока защиты информации общего назначения

5.1 Владелец

ИСО/МЭК СТК1/ПК37

5.2 Идентификатор владельца

257 (0101 Hex). Данный идентификатор присвоен биометрической организации ИСО/МЭК СТК1 /ПК37 по ИСО/МЭК 19785-2.

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

ISO/IEC JTC 1/SC 37 CBEFF general-purpose security block format

5.4 Идентификатор

1 (0001 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 с использованием DER (см. ИСО/МЭК 8825-1).

2 (0002 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 с использованием PER (см. ИСО/МЭК 8825-2).

3 (0003 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 с использованием XER (см. ИСО/МЭК 8825-3).

5.5 Идентификаторы объектов АСН.1 для данного формата

5.5.1 Запись с использованием DER

{iso registration-authority cbeff(19785) organizations(0) jtc-sc37 (257) sb-formats(3) general-purpose(0) der-encoding(1)}

или значение в нотации XML:

1.1.19785.0.257.3.0.1

5.5.2 Запись с использованием PER

{iso registration-authority cbeff(19785) organizations(0) jtc-sc37 (257) sb-formats(3) general-purpose(0) per-encoding(2)}

или значение в нотации XML:

1.1.19785.0.257.3.0.2

5.5.3 Запись с использованием XER

{iso registration-authority cbeff(19785) organizations(0) jtc-sc37 (257) sb-formats(3) general-purpose(0) xer-encoding(3)}

или значение в нотации XML:

1.1.19785.0.257.3.0.3

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

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

5.7 Идентификатор версии

Формату БЗИ, установленному в настоящем разделе, присвоен следующий идентификатор версии: основное значение - (0), вспомогательное значение - (0).

5.8 Спецификация формата и требования к соответствию

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

5.8.1.1 В настоящем разделе БЗИ представляет собой тип CBEFFSecurityBlock в нотации АСН.1, состоящий из последовательности типов CBEFFSecurityBlockElement в нотации АСН. 1.

CBEFFSecurityBlock ::= SEQUENCE OF CBEFFSecurityBlockElement

CBEFFSecurityBlockElement ::= CHOICE {

elementCBEFFSB ContentlnfoCBEFFSB,

subBlockForACBio SubBlockForACBio,

accumulatedACBiolnstances ACBiolnstances

}

5.8.1.2 Для типа CBEFFSecurityBlockElement существует три альтернативы: ContentlnfoCBEFFSB, SubBlockForACBio и ACBiolnstances. ContentlnfoCBEFFSB*(7) содержит информацию о целостности СБЗ и ББД или о шифровании ББД. Два последних типа содержат информацию об АСБио (см. ИСО/МЭК 24761).

5.8.1.3 Тип ContentlnfoCBEFFSB представляет собой следующую запись:

ContentlnfoCBEFFSB ::= SEQUENCE {

contentType CONTENT-TYPE.&id({ContentTypeCBEFF}),

content [0] EXPLICIT CONTENT-TYPE.&Type

({ContentTypeCBEFF}{@contentType})

}

Примечание - Тип CBEFFSecurityBlockElement должен быть использован в качестве замены типа Contentlnfo, требования к которому установлены в RFC 5911. Первый компонент типа CBEFFSecurityBlockElement может содержать только четыре идентификатора объектов: id-envelopeRelatedData, id-encryptionRelatedData, id-signatureRelatedData, или id-authenticationRelatedData, в то время как тип Contentlnfo, требования к которому установлены в RFC 5911, может содержать также другие идентификаторы объектов.

Тип ContentlnfoCBEFFSB используют дважды при записи CBEFFSecurityBlock: первый раз для поддержки целостности, второй - для поддержки шифрования.

Тип ContentlnfoCBEFFSB состоит из двух компонентов: contentType и content, первый из которых представляет собой идентификатор объекта для данных, содержащихся во втором компоненте. Значение contentType представляет собой один из следующих идентификаторов объектов: id-envelopeRelatedData; id-encryptionRelatedData, id-signatureRelatedData или id-authenticationRelatedData, что соответствует текущему определению типа ContentTypeCBEFF, состоящему из четырех CONTENT-TYPEs. В настоящем стандарте для типа CONTENT-TYPE предусмотрен идентификатор объекта с типом, записанным в АСН.1.

ContentTypeCBEFF CONTENT-TYPE ::= {envelopeRelatedData | encryption Related Data |

signatureRelatedData | authenticationRelatedData}

envelopeRelatedData CONTENT-TYPE ::= {

EnvelopeRelatedData

IDENTIFIED BY id-envelopeRelatedData

}

encryption Related Data CONTENT-TYPE ::= {

Encryption Related Data

IDENTIFIED BY id-encryptionRelatedData

}

signatureRelatedData CONTENT-TYPE ::= {

SignatureRelatedData

IDENTIFIED BY id-signatureRelatedData

}

authenticationRelatedData CONTENT-TYPE ::= {

AuthenticationRelatedData

IDENTIFIED BY id-authenticationRelatedData

}

Четырем вышеуказанным наименованиям объектов присвоены следующие идентификаторы объектов:

id-envelopeRelatedData OBJECT IDENTIFIER ::= {

iso(1) standard(0) cbeff(19785) contentType(1) envelopeRelatedData(1)

}

id-encryption Related Data OBJECT IDENTIFIER ::= {

iso(1) standard(0) cbeff(19785) contentType(1) encryption Related Data(2)

}

id-signatureRelatedData OBJECT IDENTIFIER ::= {

iso(1) standard(0) cbeff(19785) contentType(1) signatureRelatedData(3)

}

id-authenticationRelatedData OBJECT IDENTIFIER ::= {

iso(1) standard(0) cbeff(19785) contentType(1) authenticationRelatedData(4)

}

id-envelopeRelatedData или id-encryption Related Data используют в составе компонента contentType типа ContentlnfoCBEFFSB в случае, если элемент данных CBEFF_BDB_encryption_options (см. ИСО/МЭК 19785-1) имеет значение ENCRYPTION.

id-signatureRelatedData или id-authenticationRelatedData используют в составе компонента contentType типа ContentlnfoCBEFFSB в случае, если элемент данных CBEFF_BIR_integrity_options (см. ИСО/МЭК 19785-1) имеет значение INTEGRITY.

5.8.1.4 Данные типа SubBlockForACBio предназначены также для использования в МОБД модуля БиоАПИ, который генерирует отчет АСБио. Эти данные один МОБД модуля БиоАПИ передает другому модулю. Тип SubBlockForACBio представляет собой следующую запись:

SubBlockForACBio ::= SEQUENCE {

bpulOlndex INTEGER,

acbiolnstance ACBiolnstance

}

Первый компонент данного типа - bpulOlndex представляет собой BPU IO index*(8) блока информации при передаче от одного МОБД другому. Второй компонент является отчетом АСБио генерированным первым МОБД (ИСО/МЭК 24761).

5.8.1.5 Данные типа ACBiolnstances представляет собой последовательность отчетов АСБио исключая последний, который записывают в тип SubBlockForACBio.TaKHM образом тип ACBiolnstances представляет собой последовательность типов ACBiolnstance*(9).

ACBiolnstances ::= SEQUENCE OF ACBiolnstance

5.8.1.6 Таким образом ЗБИ может обеспечивать возможность использования:

1) шифрования, если значение ENCRYPTION установлено в элементе данных CBEFF_DBD_encryption_options или это является обязательным требованием формата ведущей организации;

2) целостности, если значение INTEGRITY установлено в элементе данных CBEFF_BlR_integrity_options или это является обязательным требованием формата ведущей организации;

3) шифрования и целостности или одного из этих компонентов, если это является требованием формата ведущей организации.

5.8.2 Шифрование

Если в элементе данных СБЗ CBEFF_BDB_encryption_options установлено значение ENCRYPTION, ЗБИ должна содержать тип ContentlnfoCBEFFSB, первым компонентом которого является id-envelopeRelatedData или id-encryptionRelatedData. В соответствии с требованиями 5.1.8.3, содержание второго компонента устанавливает первый компонент типа ContentlnfoCBEFFSB, то есть, если первым компонентом является id-envelopeRelatedData, то вторым должен быть EnvelopeRelatedData, и, если первым компонентом является id-encryptionRelatedData, то вторым должен быть EncryptionRelatedData.BBfl в этом случае должен содержать биометрические данные в зашифрованной форме.

Примечание 1 - Различия между компонентами EnvelopeRelatedData и EncryptionRelatedData зависят от системы управления ключами (см.RFC 3852).

Примечание 2 - Элементы данных СБЗ содержат значения, описывающие незашифрованный ББД (до проведения шифрования), и не описывают атрибуты зашифрованной ББД.

5.8.2.1 Содержание типа envelopeRelatedData

5.8.2.1.1 Содержание типа envelopeRelatedData устанавливает идентификатор объекта id-envelopeRelatedData в соответствии с типом EnvelopeRelatedData в нотации АСН.1 (см. 5.8.1.3).

a) EnvelopeRelatedData содержит информацию об алгоритме шифрования и зашифрованных ключах шифрования для одного или нескольких получателей. Зашифрованные биометрические данные находятся в ББД. Биометрические данные могут быть зашифрованы для произвольного числа получателей с помощью любой из поддерживаемых технологий управления ключами шифрования для каждого пользователя.

Примечание - Подробная информация о системе управления ключами шифрования приведена в RFC 3852.

b) Пользователь расшифровывает один из зашифрованных ключей шифрования, входящих в состав данных типа EnvelopeRelatedData, а затем с помощью данного ключа расшифровывает биометрические данные, находящиеся в ББД.

5.8.2.1.2 Тип EnvelopeRelatedData представляет собой следующую запись:

EnvelopeRelatedData::= SEQUENCE {

version CBEFFSBVersion DEFAULT v0,

originatorlnfo [0] IMPLICIT Originatorlnfo OPTIONAL,

recipientlnfos Recipientlnfos,

contentEncryptionAlgorithm ContentEncryptionAlgorithmldentifier

}

a) поле version предназначено для указания версии типа CBEFFSBVersion и представляет собой следующую запись:

CBEFFSBVersion ::= INTEGER {v0(0)}( v0,...)

b) поле originatorlnfo типа Originatorlnfo предназначено для указания информации об устройстве, сгенерировавшим БЗИ. Данное поле присутствует только в том случае, если этого требует алгоритм управления ключами. Данное поле может содержать сертификаты и СОС. Требования к типу Originatorlnfo установлены в RFC 3852 и RFC 5911;

c) поле recipientlnfos типа Recipientlnfos предназначено для записи информационных блоков о получателях. Данное поле должно содержать не менее одного информационного блока. Тип Recipientlnfos представляет собой последовательность типов Recipientlnfo. Требования к типу Recipientlnfo установлены в RFC 3852 и RFC 5911;

d) поле contentEncryptionAlgorithm предназначено для указания алгоритма шифрования и вспомогательных параметров, использованных для шифрования биометрических данных. Для всех пользователей указывают единый алгоритм и ключ шифрования.

5.8.2.2 Тип encryption Related Data

5.8.2.2.1 Информационное содержимое типа encryptionRelatedData представляет собой идентификатор объекта id-encryptionRelatedData в соответствии с типом EncryptionRelatedData, записанным в нотации АСН.1 (см. 5.8.1.3):

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

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

b) тип EncryptionRelatedData представляет собой следующую запись:

EncryptionRelatedData ::= SEQUENCE {

version CBEFFSBVersion DEFAULT v0, contentEncryptionAlgorithm ContentEncryptionAlgorithmldentifier

}

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

Если в элементе данных CBEFF_BIR_integrity_options установлено значение INTEGRITY, ЗБИ должен содержать тип ContentlnfoCBEFFSB, первым компонентом которого является id-signatureRelatedData или id-authenticationRelatedData. В соответствии с требованиями 5.1.8.3 содержание второго компонента устанавливает первый компонент типа ContentlnfoCBEFFSB, то есть, если первым компонентом является id-signatureRelatedData, то вторым должен быть SignatureRelatedData, и, если первым компонентом является id-authenticationRelatedData, то вторым должен быть AuthenticationRelatedData. Таким образом, тип signatureRelatedData используют в том случае, если для обеспечения целостности биометрических данных используют цифровую подпись, и тип authentication Related Data должен быть использован, если биометрические данные защищены АКС. Цифровую подпись и АКС записывают в СБЗ или в ББД (в том числе зашифрованном).

5.8.3.1 Содержание типа signatureRelatedData

5.8.3.1.1 Содержание типа signatureRelatedData устанавливает идентификатор объекта id-signatureRelatedData в соответствии с типом SignatureRelatedData, записанным в нотации АСН.1 (см. 5.8.1.3).

a) SignatureRelatedData представляет собой одну или несколько цифровых подписей. Любое количество подписывающих инстанций (далее - подписантов) могут параллельно использовать цифровую подпись для последовательности данных СБЗ и для записи ББД (в том числе зашифрованного). В отличие от типа SignedData (см. RFC 3852 и RFC 5911) тип SignatureRelatedData не содержит данных, к которым была применена цифровая подпись;

b) процесс создания SignatureRelatedData включает в себя следующие этапы, изображенные на рисунке 1 слева:

1) для каждого подписанта дайджест сообщения (или хеш-значение) вычисляют из последовательности данных СБЗ и записи ББД (в том числе зашифрованной) с использованием специфического для данного подписанта алгоритма (САПС*(10)). Результатом является сформированный дайджест сообщения (ДС*(11));

2) для каждого подписанта, к дайджесту сообщения применяют цифровую подпись с использованием закрытого ключа подписчика (ЗКП*(12)) и специфического алгоритма подписи подписчика (САПП*(13));

3) для каждого подписанта значение цифровой подписи (ЦП) и другие данные являются значением Signerlnfo, требования к которому установлены в RFC 3852 и RFC 5911. Сертификаты и СОС каждого подписанта, а также другие данные, не относящиеся к какому-либо другому подписанту, сохраняются на данном этапе;

4) специфические алгоритмы дайджеста сообщения и соответствующие значения Signerlnfo всех подписантов в свою очередь становятся значением SignatureRelatedData;

c) процесс верификации SignatureRelatedData включает в себя несколько этапов (см. справа на рисунке 1). Получатель вычисляет дайджест сообщения (ДС*(14)) из последовательности данных СБЗ и записи ББД (в том числе зашифрованной), используя специфический алгоритм дайджеста сообщения (САДС). Данный дайджест сообщения и открытый ключ подписанта (ОКП*(15)) используют для проверки значения цифровой подписи (ЦП) путем сравнения дайджеста сообщения, вычисленного в процессе верификации (ДС) и дайджеста сообщения подписанта (ДС). Значение ДС находящееся в цифровой подписи (ЦП), расшифровывают с помощью открытого ключа подписанта (ОКП) и специфического алгоритма подписи подписанта (САПП*(16)). Открытый ключ подписанта определяют с помощью наименования и оригинального серийного номера организации-разработчика данной системы цифровой подписи или с помощью идентификационного ключа для однозначной идентификации сертификата подписанта, содержащего открытый ключ. Сертификат подписанта может быть включен в содержимое поля certificates типа SignatureRelatedData.

На рисунке 1 пунктирной линией от ЗКП к полю "certificates" указан способ включения в поле "certificates" сертификата открытого ключа, относящегося к закрытому ключу подписанта.

"Рисунок 1 - Процессы создания и верификации ЦП"

5.8.3.1.2 Тип SignatureRelatedData представляет собой следующую запись:

SignatureRelatedData ::= SEQUENCE {

version CBEFFSBVersion DEFAULT v0,

digestAlgorithms SET OF DigestAlgorithmldentifier,

certificates [0] IMPLICIT CertificateSet OPTIONAL,

crls [1] IMPLICIT RevocationlnfoChoices OPTIONAL,

signerinfos Signerinfos

}

a) version представляет собой номер версии спецификации блока защиты информации типа CBEFFSBVersion по 5.8.2.1.2;

b) digestAlgorithms представляет собой значение типа DigestAlgorithmldentifiers, содержащего набор идентификаторов специфических алгоритмов дайджеста сообщения. Каждый идентификатор представлен вместе с дополнительными параметрами одного или нескольких подписантов. Данный набор содержит идентификаторы всех САДС всех подписантов в любом порядке. Настоящий стандарт не устанавливает требований к использованию определенного алгоритма криптографического хеширования;

c) certificates представляет собой набор сертификатов. Необходимо, чтобы этот набор содержал необходимую информацию о последовательности от "корневого" сертификата или сертификата от органа, выдающего сертификаты до сертификатов подписантов, записанных в поле signerinfos. Число сертификатов может быть больше, чем необходимо; возможно наличие сертификатов, достаточных для хранения последовательности сертификатов от двух и более независимых органов высшего уровня, выдающих сертификаты. Сертификатов может быть меньше в случае, если предполагается, что у получателей есть альтернативные способы получения необходимых сертификатов (например, из предыдущего набора). Сертификат подписанта также может быть включен в набор сертификатов;

d) crls представляет собой информацию об отозванных сертификатах. Данная информация позволяет определить, действительны ли сертификаты, однако данная информация не является обязательной. Списки отозванных сертификатов (СОС) являются основным источником информации об отозванных (недействительных) сертификатах. Число СОС может быть как больше, так и меньше, чем необходимо;

e) signerinfos представляет собой набор информационных элементов о подписантах. В данном компоненте может быть любое количество элементов. Требования к типу Signerlnfo установлены в RFC 3852 и RFC 5911.

5.8.3.2 Содержание типа authenticationRelatedData

5.8.3.2.1 Содержание типа authenticationRelatedData устанавливает идентификатор объекта id-authenticationRelatedData в соответствии с типом AuthenticationRelatedData, записанным в нотации АСН.1 (см. 5.8.1.3):

a) тип AuthenticationRelatedData состоит из аутентификационного кода сообщения (АКС) и зашифрованных аутентификационных ключей, предназначенных для одного или нескольких получателей. Комбинация АКС и одного аутентификационного ключа необходима получателю для проверки целостности последовательности СБЗ и ББД (в том числе зашифрованного). В отличие от содержания типа AuthenticatedData, установленного в RFC 3852, тип AuthenticationRelatedData не содержит данных, которые должны быть аутентифицированы;

b) процесс создания AuthenticationRelatedData включает в себя следующие этапы:

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

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

3) внесение в Recipientlnfo (требование к использованию типа Recipientlnfo установлены в RFC 3852 и RFC 5911) зашифрованного аутентификационного ключа сообщения и другой специфической для получателя информации;

4) вычисление отправителем АКС с использованием аутентификационного ключа сообщения на основании последовательности СБЗ и ББД (в том числе зашифрованного). АКС записывают в поле mac.

5.8.3.2.2 Тип AuthenticationRelatedData представляет собой следующую запись: AuthenticationRelatedData ::= SEQUENCE {

version CBEFFSBVersion DEFAULT v0,

originatorlnfo [0] IMPLICIT Originatorlnfo OPTIONAL,

recipientlnfos Recipientlnfos,

macAlgorithmMessageAuthenticationCodeAlgorithm,

mac MessageAuthenticationCode

}

a) version представляет собой номер версии спецификации БЗИ;

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

c) recipientlnfos предназначен для набора информации о получателе. В данном наборе должен быть, как минимум, один элемент;

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

e) mac представляет собой АКС.

5.8.4 Шифрование и проверка целостности

5.8.4.1 Если элементы данных CBEFF_BDB_encryption_options и CBEFF_BIR_integrity_options поддерживаются СБЗ и их значениями являются ENCRYPTION и INTEGRITY соответственно, БЗИ должен содержать элементы шифрования и проверки целостности.

5.8.4.2 Шифрование должно быть проведено до проверки целостности. Последовательность действий должна быть следующей:

1) биометрические данные (ББД) зашифровывают и записывают в поле ББД;

2) генерируют данные типов EnvelopeRelatedData или EncryptionRelatedData и вносят их в БЗИ;

3) из последовательности СБЗ и ББД генерируют одну или несколько цифровых подписей или АКС;

4) генерируют данные типов SignatureRelatedData или AuthenticationRelatedData и включают их в БЗИ.

5.8.4.3 Проверку целостности проводят до процесса расшифровывания. Последовательность действий должна быть следующей:

1) одну или несколько цифровых подписей или АКС получают из данных типов SignatureRelatedData или AuthenticationRelatedData БЗИ;

2) проверку целостности последовательности СБЗ и зашифрованного ББД проводят с помощью цифровой подписи или АКС;

3) информацию о шифровании получают из данных типов EnvelopeRelatedData или EncryptionRelatedData БЗИ;

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

5.9 Запись абстрактных значений

Запись данных БЗИ проводят следующим образом:

a) побитовую запись СБЗ проводят в соответствии с требованиями используемого формата ведущей организации;

b) побитовую запись ББД проводят в соответствии с требованиями спецификации формата ББД;

c) запись CBEFFSecurityBlock проводят в соответствии с подразделом 5.5 и приложением А настоящего стандарта.

6 Формат блока защиты информации, использующий только цифровую подпись

6.1 Владелец

ИСО/МЭК СТК1/ПК37

6.2 Идентификатор владельца организации

257 (0101 Hex). Данный идентификатор присвоен биометрической ИСО/МЭК СТК1/ПК37 в соответствии с требованиями ИСО/МЭК 19785-2.

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

ISO/IEC JTC1/SC 37 signature-only security block format

6.4 Идентификатор

4 (0004 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 для кодирования с использованием DER (см. ИСО/МЭК 8825-1).

5 (0005 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 для кодирования с использованием PER (см. ИСО/МЭК 8825-2).

6 (0006 Hex). Данный идентификатор зарегистрирован в соответствии с требованиями ИСО/МЭК 19785-2 для кодирования с использованием XER (см. ИСО/МЭК 8825-3).

6.5 Идентификаторы объектов АСН.1 для данного формата

6.5.1 Запись с использованием DER

{iso registration-authority cbeff(19785) biometric-organization(0) jtc1-sc37(257) sbformats(3) signature-only(2) der-encoding(1)}

или значение в нотации XML:

1.1.19785.0.257.3.2.1

6.5.2 Запись с использованием PER

{iso registration-authority cbeff(19785) biometric-organization(0) jtc1-sc37(257) sbformats(3) signature-only(2)per-encoding(2)}

или значение в нотации XML:

1.1.19785.0.257.3.2.2

6.5.3 Запись с использованием XER

{iso registration-authority cbeff( 19785) biometric-organization(0) jtc1-sc37(257) sbformats(3) signature-only(2)xer-encoding(3)}

или значение в нотации XML:

1.1.19785.0.257.3.2.3

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

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

Примечание - Данный формат соответствует требованиям [4].

6.7 Идентификатор версии

Формату ЗБИ, установленному в настоящем разделе, присвоен следующий идентификатор версии: основное значение - (0), вспомогательное значение - (0).

6.8 Спецификация формата и требования к соответствию

Блок защиты информации, использующий только цифровую подпись, должен представлять собой запись, соответствующую требованиям RFC 3852, или данные типа SignedData в нотации АСН.1, соответствующие требованиям вышеуказанного документа.

Примечание - В RFC 3852 установлено требование к использованию отличительных (DER) правил кодирования (ИСО/МЭК 8825-1*(17)) для записи SignedData.

Цифровую подпись применяют к записи, соответствующей требованиям ЕСФОБД (СБЗ и ББД) за исключением БЗИ, использующего только цифровую подпись.

Данный формат БЗИ должен соответствовать следующим требованиям, установленным в RFC 3852:

- значением CMSVersion должно быть v3;

- encapcontentlnfo не должно содержать поля eContent field;

- поле certificates должно иметь нулевое значение или содержать один certificate (если такое требование установлено конкретным применением), который используют для проверки signature записанного в поле Signerlnfo;

- поле crls не используют;

- поле signerlnfos должно содержать один Signerlnfo;

- Signerlnfo должен содержать:

- значение issuerAndSerialNumber для элемента Signerldentifier;

- атрибут MessageDigest для хеш-значения последовательности СБЗ и ББД.

_______________________________

*(1) МОТ - Международная организация труда.

*(2) RFC 3852 Cryptographic Message Syntax (CMS) - регламентирующий документ Специальной комиссии интернет-разработок (Internet Engineering Task Force, IETF), обеспечивающий защиту информации, передаваемой в сети Интернет.

*(3) EnvelopedData, EncryptedData, SignedData и AuthenticatedData - упакованные данные, зашифрованные данные, данные с электронной подписью и данные из аутентифицированного источника соответственно.

*(4) Authentication Context for Biometrics (ACBio) - аутентификационный статус для биометрии (АСБио).

*(5) Telebiometric authentication infrastructure (TAI) - аутентификационная телебиометрическая инфраструктура.

*(6) Список отозванных сертификатов (СОС) - certificate revocation list (CRL).

*(7) В оригинале ИСО/МЭК 19785-4 допущена ошибка - вместо ConfenfInfoCBEFFSB указано CBEFFSecurityBlockElement.

*(8) BPU 10 index - см. ИСО/МЭК 24761.

*(9) В оригинале ИСО/МЭК 19785-4 вместо ACBiolnstance ошибочно указано ACBiolnstances.

*(10) САДС (специфический алгоритм дайджеста сообщения) - signer-specific message-digest algorithm (DA).

*(11) ДС (дайджест сообщение) - message digest (MD).

*(12) ЗКП (закрытый ключ подписчика) - signer's private key (PrK).

*(13) САПП (специфический алгоритм подписи подписанта) - signer-specific signature algorithm (SA).

*(14) В оригинале ИСО/МЭК 19785-3 допущена опечатка - вместо сокращения DS указано сокращение DS'.

*(15) Открытый ключ подписанта (ОКП) - signer's public key (PbK).

*(16) В оригинале ИСО/МЭК 19785-3 допущена опечатка - вместо сокращения SA указано сокращение DS.

*(17) В оригинале ИСО/МЭК 19785-4 вместо ISO/IEC 8825-1 ошибочно указано ISO 8825-1.

_______________________________

* В оригинале ИСО/МЭК 19785-4 вместо encryptedContentlnfo ошибочно указано encryptionContentlnfo.

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

[1]	ISO/IEC 19785-2	(Information technology - Common Biometric Exchange Formats Framework - Part 2: Procedures for the operation of the Biometric Registration Authority)
[2]	ISO/IEC 24713-3	Information technology - Biometric profiles for interoperability and data interchange - Part 3: Biometrics-based verification and identification of seafarers
[3]	ITU-T Rec. X. 1089	Telebiometrics authentication infrastructure
[4]	FIPS PUB 201-1 (Change Notice 1)	Federal Information Processing Standards Publication, Personal Identity Verification (PIV) of Federal Employees and Contractors