Cryptographic Message Syntax

Cryptographic Message Syntax (CMS) е интернет стандарт, създаден от Internet Engineering Task Force (IETF) за криптографски защитени съобщения. Той може да бъде използван за цифрово подписване, хеширане, удостоверяване или криптиране на всякакъв вид цифрови данни.

История и развитие

Cryptographic Message Syntax използва като основа синтаксиса на стандарта PKCS#7, който е създаден извън IETF и е публикуван за първи път през ноември 1993 г. от RSA Laboratories. Той от своя страна е базиран върху стандарта Privacy-Enhanced Mail.^[1] Последната версия на CMS (към 2009 г.) е дефинирана в RFC 5652 (вижте също и RFC 5911 за обновените Abstract Syntax Notation One (ASN.1) модули, съответстващи на по-рано приетият стандарт ASN.1 2002). Архитектурата на CMS е изградена върху управлението на сертификационни ключове, точно както профилът определен от работната група на стандартите PKIX.

Промени от PKCS #7 версия 1.5

RFC 2630 [CMS1] е първата записана стандартизирана версия на CMS от IETF. Съвместимостта с PKCS #7 версия 1.5 е запазена където е било възможно. Въпреки това, промени настъпват за да се имплементира версия 1 характерен сертифициран трансфер и за да се поддържа независим алгоритъм при управлението на ключове. PKCS #7 версия 1.5 включва поддръжка само на транспортиране на ключове. RFC 2630 добавя поддръжка за съвместимост на ключовете и за разпространените преди това симетрично ключово криптиране и ключови техники.

Промени от [rfc:2630 RFC_2630]

RFC_3369 прави излишен RFC_2630 [CMS1] и RFC_3211 [PWRI].

В спецификацията на CMS е включено управление на ключове защитени с парола и допълнителен механизъм за поддръжка и управление на нов ключови схеми. Запазва се съвместимостта с RFC_2630 и RFC_3211. Все пак е добавена версия 2 характерен сертифициран трансфер и използването на версия 1 характерен сертифициран трансфер е отхвърлена.

S/MIME v 2 (Secure/Multipurpose Internet Mail Extensions) подписи MSG 2, които се основават на PKCS#7 версия 1.5, са съвместими с S/MIME v 3 подписи MSG3 и S/MIME v 3.1 подписи MSG 3.1. Има все пак някои малки проблеми със съвместимостта с подписи основани на PKCS#7 версия 1.5.

Промени от RFC_3369

RFC_3852 CMS3 замества RFC_3369 CMS2. Както бе обсъдено в предишната точка, RFC 3369 въвежда допълнителен механизъм за поддръжка и управление на нов ключови схеми без по-нататъшни промени в CMS. RFC 3852 въвежда подобен механизъм за поддръжка на ново добавени сертификат формати. Съвместимостта с по-стари версии на CMS е запазена.

След публикуването на RFC 3369, са били забелязани няколко неточности в документацията които са публикувани на интернет страницата на RFC Editor.

Промени от RFC_3852

Този документ замества RFC 3852 CMS3. Основната причина за публикуването на този документ е да придвижи по-напред CMS в класацията на стандартите. Този документ включва уточненията, които са първоначално публикувани в RFC 4853 (CMSMSIG) относно правилното обработване на защитени подписани данни при наличие на повече от един цифров подпис.

След публикуването на RFC 3852 отново са били забелязани няколко неточности в документацията които са публикувани на интернет страницата на RFC Editor.

Номерация на версиите

Всяка от основните структури данни включва номер на версия като първи елемент в структурата от данните. Номерата на версиите са за да се избегнат ASN.1 грешки при разкодирането. Някои приложения не проверяват номера на версията преди да опитат декодиране и ако се появи грешка в декодирането, номера на версията се проверява като част от работата по обработване на грешката. Това е разумен подход, който поставя обработването на грешките извън бързия път. Този подход също „прощава“ когато изпращача използва неправилен номер на версията.

Повечето от първоначалните номера на версии са създадени в PKCS #7 версия 1.5. Други са добавени когато първоначално е създадена структурата. Всеки път когато една структура се актуализира се използва по-висок номер номер на версия. Също така, за де се гарантира максимална оперативна съвместимост, по висок номер на версия се използва само когато нова синтактична функция е вкарана в експлоатация. В случая се използва най-ниската версия която поддържа даден генериран синтаксис.

Общ преглед

CMS е достатъчно обширен и да поддържа много различни типове съдържание. Защитата на съдържанието капсулира един определен тип съдържание, който от своя страна може да осигури допълнително капсулиране. Този документ дефинира шест типове съдържание. Допълнителни типове съдържание могат също да бъдат дефинирани извън този документ.

Като част от основната дизайнерска философия, всеки тип съдържание позволява еднократна обработка използвайки BER(Basic Encoding Rules) с неопределена дължина. Операции с еднократно минаване са особено полезни ако съдържанието е голямо, съхранявано на ленти, или е свързано с друг процес. Еднократните операции обаче имат един значителен недостатък: трудно се извършват операции използващи отличителни правила за кодиране (Distinguished Encoding Rules (DER) X.509 – 88) с еднократно минаване, защото дължините на различните компоненти може да не са предварително дефинирани. Въпреки това, подписани и заверени в рамките на типа съдържание атрибути трябва да бъдат предадени в DER форма, за да гарантират, че получателите могат да проверят съдържание, което съдържа един или повече неразпознаваеми атрибути. Подписани атрибути и заверени атрибути са единствените видове данни използвани в CMS, който изискват DER кодиране.

Типове съдържание

В последната версия на CMS стандарта (RFC 5652) са представени шест типа съдържание: данни, подписани данни, опаковани данни, хеширани данни, криптирани данни и удостоверени данни. Освен тях е предоставена възможност за добавяне и на други извън документацията RFC 5652.^[2]

Данни

Типът Данни се отнася до октетни (байтови) низове с произволна дължина, например ASCII текстови файлове; интерпретацията е оставена на приложението. Такива низове не е необходимо да съдържат някаква вътрешна структура (въпреки че те биха могли да имат собствена ASN.1 дефиниция или друга структура).

Този тип съдържание обикновено се използва в останалите типове, които са разгледани по-долу.

Обектът OBJECT IDENTIFIER идентифицира типа съдържание на данните:

     id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

Подписани данни

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

Типичното приложение на подписаните данни е дигиталният подпис на един от авторите върху съдържанието на типа Данни. Друго типично приложение е разпространяването на сертификати и списъци с отменени сертификати (certificate revocation lists (CRL)).

Процесът са на създаване на подписани данни се състои от следните стъпки:

1. За всеки автор се създава хеш стойност (наричана още message digest или само digest) на съдържанието чрез специален специален алгоритъм, който съществува само за този автор. Така се гарантира целостта на данните.
2. Към хеш стойността на всеки автор се добавя дигитален подпис чрез неговия личен ключ. По този начин се удостоверява неговата самоличност.
3. За всеки автор стойността на подписа и друга специфична за него информация се обединяват в обща стойност – SignerInfo value. Сертификатите и списъците с отменени сертификати за всеки от авторите и тези, които не са свързани с никой от тях се добавят на тази стъпка.
4. Хеширащите алгоритми за всички автори и техните SignerInfo стойности се обединяват заедно със съдържанието в стойността SignedData.

Чрез обекта OBJECT IDENTIFIER се определя типа Подписани данни:

     id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Опаковани данни

Опакованите данни могат да съдържат всякакъв тип криптирани данни и криптирани ключове за един или повече получатели. Комбинацията от криптирано съдържание и криптиран ключ за получателя се нарича „дигитален плик“ за този получател. Всеки тип съдържание може да бъде опакован за произволен брой получатели, чрез използване на която и да е от поддържаните техники за управление на ключовете на получателите.

Обичайното приложение на опакованите данни е да се създават дигитални пликове за типовете Данни и Подписани данни.

Опакованите данни се създават в следните стъпки:

1. Генерира се произволен криптиращ ключ по предварително определен алгоритъм.
2. Съдържанието на криптиращия ключ се криптира на свой ред за всеки от получателите. Извършването на това криптиране зависи от използвания алгоритъм за управление на ключовете, но има четири основни техники, които се поддържат:
   1. транспорт на ключа: съдържанието на криптиращия ключ се криптира с публичния ключ на получателя.
   2. съгласуване на ключовете: публичният ключ на получателя и личният ключ на изпращача се използват за създаване на симетричен ключ, след което с него се кодира ключът, с който са криптирани данните.
   3. симетрични ключове: криптиращият ключ се кодира с предварително получен симетричен ключ
   4. пароли: криптиращият ключ се кодира с друг криптиращ ключ, който е получен от парола или друга споделена тайна стойност.
3. За всеки получател криптираният ключ и всяка свързана с него информация се обединява в стойността RecipientInfo.
4. Съдържанието се криптира с криптиращия ключ.
5. Стойностите RecipientInfo за всички получатели се обединяват заедно с криптираното съдържание, за да образуват стойността EnvelopedData.

Получателят отваря опакованото съобщение като първо декриптира криптиращия ключ и след това с него декриптира самото съобщение.

Чрез обекта OBJECT IDENTIFIER се определя типа Опаковани данни:

     id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Хеширани данни

Хешираните данни съдържат в себе си всякакъв тип данни и тяхната хеш стойност.

Обикновено хешираните данни се използват, за да осигурят цялост на съдържанието и резултатът най-често се опакова в дигитален плик и става част от типа Опаковани данни.

Създаването на хеширани данни се извършва в следните стъпки:

1. Чрез специален алгоритъм се създава хеш стойност на съдържанието
2. Хеширащият алгоритъм и хеша се обединяват заедно със съдържанието в стойността DigestedData.

Получателят проверява дали съобщението е непроменено чрез сравняване на хеш стойността с независимо генерирана нова хеш стойност на полученото съобщение.

Чрез обекта OBJECT IDENTIFIER се определя типа Хеширани данни:

     id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Криптирани данни

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

Обичайното приложение на криптираните данни е криптиране на съдържанието на типа Данни за локално съхранение като често криптиращият ключ се извлича от парола.

Чрез обекта OBJECT IDENTIFIER се проверява типа Криптирани данни:

     id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

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

Authenticated-Data – this consists of the content, message authentication code (MAC), and encrypted authentication keys for one or more recipients. OpenSSL е софтуер с отворен код, който може да криптира, декриптира, подписва и удостоверява, компресира и декомпресира CMS документи.

Удостоверените данни съдържат данни от всеки тип, удостоверение за автентичност на съобщението (message authentication code (MAC)) и криптирани удостоверяващи ключове за един или повече получатели. Комбинацията от MAC и един криптиран удостоверяващ ключ за конкретен получател са необходими на този получател, за да провери целостта на съдържанието.

Целостта на всеки тип съдържание може да бъде защитена за произволен брой получатели.

Процесът на създаване на удостоверени данни е в следните няколко стъпки:

1. По предварително определен алгоритъм се създава произволен ключ за удостоверяване на съобщението
2. Удостоверяващият ключ се криптира за всеки получател поотделно. Процесът на криптиране зависи от използвания алгоритъм за управление на ключовете.
3. За всеки получател, криптираният удостоверяващ ключ и друга специфична за получателя информация се обединяват в стойността RecipientInfo.
4. Чрез ключа за удостоверяване авторът изчислява MAC стойността на съдържанието. Ако авторът удостоверява друга информация в допълнение към съдържанието, се създава хеш код на съдържанието и после този хеш код и допълнителната информация се удостоверяват чрез удостоверяващия ключ и резултатът става MAC стойността.

Чрез обекта OBJECT IDENTIFIER се определя типа Удостоверени данни:

     id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
        ct(1) 2 }

Приложение

CMS се използва като ключов криптографски компонент в много стандарти като S/MIME, PKCS#12 и RFC 3161 Digital timestamping protocol. В основата си той използва публични криптографски ключове, при които ключът за кодиране на данните (публичен) се различава от ключа за декодиране (таен). По този начин изпращачът на съобщението не споделя кода за декодиране с никого и това прави комуникацията много по-сигурна.

CMS предоставя възможност и за влагане на различни видове защита на данни (едно съобщение може да бъде подписано с дигитален подпис и след това криптирано или да се криптира и после да се подпише).

Вижте също

• CAdES – CMS Advanced Electronic Signatures
• S/MIME
• PKCS#7

Източници

1. Cryptographic Message Syntax – RFC 5652 // IETF.
2. Cryptographic Message Syntax (CMS) // IETF.

Външни препратки

• RFC 5652 (Cryptographic Message Syntax (CMS), in use)
• RFC 3852 (Cryptographic Message Syntax (CMS), obsolete)
• RFC 3369 (Cryptographic Message Syntax (CMS), obsolete)
• RFC 2630 (Cryptographic Message Syntax, obsolete)
• RFC 6268 (New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME, in use)
• RFC 5911 (New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME, updated)
• RFC 5753 (Using Elliptic Curve Cryptography with CMS, in use)
• RFC 3278 (Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), obsolete)
• RFC 5084 (Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS), in use)

Тази страница частично или изцяло представлява превод на страницата Cryptographic Message Syntax в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​ ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​