SPKM ( — простой механизмМеханизм (mechanism) — реализация нижележащего уровня GSS-API, обеспечивающая фактические имя, удостоверение и маркеры GSS-API на основе инфраструктуры с открытым ключом) — сетевой протокол, обладающий инфраструктурой с открытым, а не симметричным ключом. Протокол применяется для аутентификации, формирования ключей, сохранения целостности и конфиденциальности данных.
История и причины появления В сентябре 1993 года была опубликована первая версия GSS-API, и к этому же времени появляется механизм Kerberos V5. Но несмотря на то, что Kerberos 5 стал широко используемым, устоявшимся во многих системах протоколом, в некоторых приложениях было необходимо иметь GSS-API, построенный на инфраструктуре с открытыми, а не симметричными ключами. Это привело к созданию Карлайлом Адамсом (Carlisle Adams) в октябре 1996 года протокола SPKM (его первых двух разновидностей). Однако, при создании в 2000 году NFSv4 возникла проблема взаимной аутентификации и создания защищённого канала между анонимным пользователем и сервером, что привело к появлению SPKM-3.
Особенности протокола Протокол дает возможность использовать как одностороннюю, так и взаимную (двустороннюю) аутентификацию без использования меток доверенного времени. Это позволяет даже системам, не имеющим доступа к доверенному времени, тем не менее пользоваться безопасной проверкой подлинности. Также протокол использует идентификаторы алгоритмов для согласования алгоритмов, используемых общающимися сторонами, что делает его достаточно гибким при использовании в разных средах и по отношению к будущим изменениям в алгоритмах. Разрешает использование электронных подписей, основанных на асимметричных алгоритмах, а не контрольную сумму целостности, использующую MAC, полученный с помощью симметричного алгоритма (например, DES). SPKM поддерживает возможность инициатора остаться неизвестным в то время как целевой пользователь аутентифицирован, это желательная (или необходимая) опция аутентификации в некоторых средах. Управление ключами, используемое в данном механизме подразумевает совместимость как с X.509, так и с PEM. В процессе установления соединения в протоколе возможна полная договорённость сторон по алгоритмам конфиденциальности и целостности данных, алгоритмам создания ключей. В результате среда может поддерживать любое число взаимосогласованных, конфиденциальных и целостных алгоритмов, которые могут быть выбраны приложением свои на каждое сообщение, в зависимости от индивидуальных требований по защите. Форматы данных и процедуры SPKM и Kerberos схожи друг с другом, что упрощает внедрение SPKM в среде, использующей протокол Kerberos.Carlisle Adams IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services
Из выше перечисленных свойств следует, что SPKM обладает гибкостью и функциональностью, без излишней сложности и накладных расходов на внедрение. Так как SPKM соответствует GSS-API, то он может быть использован приложением в качестве альтернативного сетевого протокола безопасности (например вместо Kerberos).
Обзор Описание общего программного интерфейса служб безопасности (GSS-API), согласно можно разделить на 2 части: Документы, определяющие конкретные привязки параметров для конкретных языковых сред. Документы, определяющие форматы маркеровМаркер (token) — непрозрачное (для приложения) сообщение, которое отсылается на этапе установления соединения или в ходе передачи защищённого сообщения, протоколов и процедур, которые будут исполняться в процессе реализации сервисов GSS-API над конкретными механизмами безопасности.
SPKM является примером последнего типа документов, и поэтому называется «GSS-API механизм». Этот механизм обеспечивает проверку подлинности, создание ключей, целостность данных, и конфиденциальность данных в распределённых приложениях в режиме онлайн, с использованием инфраструктуры открытых ключей. SPKM может быть использован, как замена любому другому приложению, использующему службы безопасности через GSS-API вызовы (например, приложение, которое уже использует Kerberos GSS-API). Использование инфраструктуры открытых ключей позволяет использовать электронные подписи для поддержания невозможности отказа от авторства при обмене сообщениями, а также предоставляет другие преимущества, такие как масштабируемость для больших групп пользователей.
Маркеры, определённые в SPKM, предназначены для использования прикладными программами в соответствии с рабочей парадигмой GSS-API. Она работает следующим образом. Обычно GSS-API вызывается сетевым протоколом (или приложением его использующим) для того, чтобы защитить соединение с помощью аутентификации, служб обеспечения конфиденциальности и/или целостности данных. При вызове GSS-API протокол (приложение) принимает маркеры, предоставленные ему своей (локальной) реализацией GSS-API (то есть GSS-API механизмом), и передаёт маркеры на удалённую систему, на том конце происходит получение маркера и его дальнейшая обработка уже своим GSS-API механизмом. Таким образом, GSS-API сам по себе не обеспечивает сервисов безопасности, вместо этого он обеспечивает интерфейс между приложениями и реализациями GSS-API (механизмами). А они в свою очередь обеспечивают совместимый с GSS-API интерфейс, позволяя создавать приложения, способные работать с разными механизмами безопасности; позволяя заменять механизмы без необходимости переписывать приложения.
Алгоритмы Для того чтобы обеспечить хотя бы минимальную совместимость между различными реализациями SPKM, один из алгоритмов целостности был сделан обязательным (MANDATORY), а все остальные алгоритмы и примеры поддерживаются различными реализациями опционально, некоторые алгоритмы также обозначены как рекомендуемые (RECOMMENDED), это сделано для увеличения совместимости.
В протоколе SPKM используются следующие алгоритмы: Целостности данных — I-ALG Конфиденциальности — C-ALG Образования ключа — K-ALG Получения подключей — O-ALG
Алгоритмы целостности данных Используются, чтобы убедиться, что данные не были изменены третьей стороной. В зависимости от алгоритма, может обеспечивать также достоверность и невозможность отказа от авторства сообщения.
В качестве примеров могут использоваться следующие алгоритмы (ниже указаны идентификаторы алгоритмов):
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 //заимствовано из PKCS#1
Данный алгоритм является обязательным (MANDATORY) для SPKM. Он обеспечивает целостность и подлинность данных, а также невозможность отказа от авторства, вычисляя электронную RSA подпись на основе MD5 хеш-функции. Так как на данный момент этот алгоритм является единственным обязательным алгоритмом проверки целостности и подлинности, то для обеспечения взаимодействия было также предусмотрено, чтобы md5WithRSA был алгоритмом подписи всех маркеров установления соединения, в которых целостность проверяется с помощью подписи, а не на основе MAC. Возможно в будущем появятся и другие обязательные алгоритмы, и тогда это условие, накладываемое на маркеры исчезнет.
DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) //хранит длину MAC в битах как целое число, algorithm(2) 10 //ограниченное кратными 8, от 16 до 64
Этот алгоритм является рекомендуемым (RECOMMENDED), целостность обеспечивается посредством использования MAC на основе DES.
md5-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) md5-DES-CBC(1)
Здесь целостность данных обеспечивается шифрованием на основе DES-CBC и «замешанного» MD5-хеширования. Это на практике быстрее, чем вычисление DES-MAC, если входные данные малы (порядка нескольких байт). Заметим, что без «замешивания» стойкость целостности механизма не более или равна стойкости DES при атаке с известным открытым текстом.
sum64-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) sum64-DES-CBC(2)
Данный алгоритм обеспечивает целостность данных посредством шифрования с помощью DES CBC. Конкатенация «замешанных» данных и суммы всех входных блоков данных (сумма вычисляется с помощью сложения по модулю 264 — 1). Таким образом, в этом алгоритме шифрование является необходимым условием обеспечения целостности данных.
Алгоритмы конфиденциальности Эти симметричные алгоритмы используются для шифрования данных для вызовов GSS-API : gss_seal() / gss_wrap().
Пример:
DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7
Этот алгоритм является рекомендуемым (RECOMMENDED).
Алгоритмы образования ключа Используются для создания симметричного ключа используемого узлами во время соединения. Далее из этого ключа создаются подключи для алгоритмов целостности и конфиденциальности. Создание ключа проходит во время обмена аутентификациями по стандарту X.509, так что полученный симметричный ключ является аутентифицированным.
Примеры:
RSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 // заимствовано из PKCS#1 и RFC-1423
В этом обязательном (MANDATORY) алгоритме ключ соединения создаётся его инициатором с помощью открытого RSA ключа цели и посылается ей. Цели, в свою очередь, не обязательно отвечать, чтобы ключ был создан.
dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1
В этом примере ключ создаётся обоими узлами с использованием алгоритма Диффи-Хеллмана. Таким образом, цель должна ответить инициатору для установления соединения (следовательно, этот алгоритм не может быть использован с односторонней аутентификацией в SPKM-2).
Односторонняя функция для алгоритма получения подключей Создав ключ соединения с помощью K-ALG, узлы должны получить набор подключей для алгоритмов конфиденциальности и целостности. Для этого используются односторонние функции. Пусть перечень принятых алгоритмов конфиденциальности пронумерован последовательно, то есть первому алгоритму (алгоритму по умолчанию) присвоен номер 0, второму — номер 1 и так далее. Пусть список алгоритмов целостности пронумерован таким же образом. Наконец, пусть ключ соединения будет двоичной строкой произвольной длины M, с учётом ограничений: L ≤ M ≤ U Битовая длина ключа соединения должна быть больше, чем наибольшая битовая длина подключей (C-ALG или I-ALG), и, в то же время, она ограничена сверху входными параметрами алгоритма формирования ключа (K-ALG).
Например, при использовании DES и 3-DES в алгоритмах конфиденциальности и DES-MAC в алгоритме целостности, ключ соединения должен составлять, по крайней мере, 112 бит. А при использовании 512-битного RSA, возможная длина составляет 424 бит (наибольший допустимый входной параметр RSAEncryption, описанный в PKCS#1). С другой стороны, при использовании алгоритма dhKeyAgreement, ключ соединения вычисляется по алгоритму Диффи-Хеллмана (за исключением старшего байта, который отбрасывается по соображениям безопасности), таким образом его длина будет на 8 битов меньше чем модуль p, что составляет примерно 1000 бит.
Алгоритм получения k-битного подключа определяется следующим образом:
rightmost_k_bits ( OWF ( context_key || x || n || s || context_key ) ) где:
context_key — ключ соединения; x — ASCII символ «C» (0x43) при создании подключа для алгоритма конфиденциальности, ASCII символ «I» (0x49) при создании подключа для алгоритма целостности; n — номер алгоритма в соответствующем разрешенном списке (ASCII символ «0» (0x30), «1» (0x31), и так далее); s — «этап» обработки — всегда равняется ASCII символом «0» (0x30), если «k» не больше выходного размера односторонней функции (OWF), в этом случае односторонняя функция считается повторно с увеличением значения «этапа» (каждое выходное значение OWF дописывается к концу предыдущих), до тех пор, пока не будет образовано «k» битов; || — операция конкатенации; OWF — соответствующая односторонняя функция.
Примеры: