User:Atanasbg/sandbox

From Wikipedia, the free encyclopedia

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

История[edit]

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.[2]

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

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

Данни[edit]

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

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

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

Подписани данни[edit]

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

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

  1. За всеки автор се създава хеш стойност(наричана още message digest или само digest[4]) на съдържанието чрез специален специален алгоритъм, който съществува само за този автор. Така се гарантира целостта на данните.
  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 }

Опаковани данни[edit]

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

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

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

  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 }

Хеширани данни[edit]

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

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

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

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


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

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

Криптирани данни[edit]

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

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

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

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

Удостоверени данни[edit]

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 }

Приложение[edit]

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

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

Вижте също[edit]

Източници[edit]

  1. ^ "Cryptographic Message Syntax - RFC 5652". IETF.
  2. ^ "X.509".
  3. ^ "Cryptographic Message Syntax (CMS)". IETF.
  4. ^ "Cryptographic Hash Function".

Външни препратки[edit]

  • 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)

Категория:Стандарти в Интернет

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Atanasbg/sandbox&oldid=715959922"