SPKM

В сентябре 1993 года была опубликована первая версия GSS-API[2][3], и к этому же времени появляется механизм Kerberos V5[4]. Но несмотря на то, что Kerberos 5 стал широко используемым, устоявшимся во многих системах протоколом, в некоторых приложениях было необходимо иметь GSS-API, построенный на инфраструктуре с открытыми, а не симметричными ключами. Это привело к созданию Карлайлом Адамсом (Carlisle Adams) в октябре 1996 года протокола SPKM (его первых двух разновидностей). Однако, при создании в 2000 году NFSv4 возникла проблема взаимной аутентификации и создания защищённого канала между анонимным пользователем и сервером, что привело к появлению SPKM-3.

• Протокол дает возможность использовать как одностороннюю, так и взаимную (двустороннюю) аутентификацию без использования меток доверенного времени. Это позволяет даже системам, не имеющим доступа к доверенному времени, тем не менее пользоваться безопасной проверкой подлинности.
• Также протокол использует идентификаторы алгоритмов для согласования алгоритмов, используемых общающимися сторонами, что делает его достаточно гибким при использовании в разных средах и по отношению к будущим изменениям в алгоритмах.
• Разрешает использование электронных подписей, основанных на асимметричных алгоритмах, а не контрольную сумму целостности, использующую MAC, полученный с помощью симметричного алгоритма (например, DES).
• SPKM поддерживает возможность инициатора остаться неизвестным в то время как целевой пользователь аутентифицирован, это желательная (или необходимая) опция аутентификации в некоторых средах.
• Управление ключами, используемое в данном механизме подразумевает совместимость как с X.509, так и с PEM.
• В процессе установления соединения в протоколе возможна полная договорённость сторон по алгоритмам конфиденциальности и целостности данных, алгоритмам создания ключей. В результате среда может поддерживать любое число взаимосогласованных, конфиденциальных и целостных алгоритмов, которые могут быть выбраны приложением свои на каждое сообщение, в зависимости от индивидуальных требований по защите.
• Форматы данных и процедуры SPKM и Kerberos схожи друг с другом, что упрощает внедрение SPKM в среде, использующей протокол Kerberos.[5]

Из выше перечисленных свойств следует, что SPKM обладает гибкостью и функциональностью, без излишней сложности и накладных расходов на внедрение. Так как SPKM соответствует GSS-API, то он может быть использован приложением в качестве альтернативного сетевого протокола безопасности (например вместо Kerberos)[6].

Описание общего программного интерфейса служб безопасности (GSS-API), согласно можно разделить на 2 части[2]:

• Документы, определяющие конкретные привязки параметров для конкретных языковых сред.
• Документы, определяющие форматы маркеров[7], протоколов и процедур, которые будут исполняться в процессе реализации сервисов GSS-API над конкретными механизмами безопасности.

SPKM является примером последнего типа документов, и поэтому называется «GSS-API механизм». Этот механизм обеспечивает проверку подлинности, создание ключей, целостность данных, и конфиденциальность данных в распределённых приложениях в режиме онлайн, с использованием инфраструктуры открытых ключей. SPKM может быть использован, как замена любому другому приложению, использующему службы безопасности через GSS-API вызовы (например, приложение, которое уже использует Kerberos GSS-API). Использование инфраструктуры открытых ключей позволяет использовать электронные подписи для поддержания невозможности отказа от авторства при обмене сообщениями, а также предоставляет другие преимущества, такие как масштабируемость для больших групп пользователей.

Маркеры, определённые в SPKM, предназначены для использования прикладными программами в соответствии с рабочей парадигмой GSS-API[2]. Она работает следующим образом. Обычно GSS-API вызывается сетевым протоколом (или приложением его использующим) для того, чтобы защитить соединение с помощью аутентификации, служб обеспечения конфиденциальности и/или целостности данных. При вызове GSS-API протокол (приложение) принимает маркеры, предоставленные ему своей (локальной) реализацией GSS-API (то есть GSS-API механизмом), и передаёт маркеры на удалённую систему, на том конце происходит получение маркера и его дальнейшая обработка уже своим GSS-API механизмом. Таким образом, GSS-API сам по себе не обеспечивает сервисов безопасности, вместо этого он обеспечивает интерфейс между приложениями и реализациями GSS-API (механизмами). А они в свою очередь обеспечивают совместимый с GSS-API интерфейс, позволяя создавать приложения, способные работать с разными механизмами безопасности; позволяя заменять механизмы без необходимости переписывать приложения.

Для того чтобы обеспечить хотя бы минимальную совместимость между различными реализациями SPKM, один из алгоритмов целостности был сделан обязательным (MANDATORY), а все остальные алгоритмы и примеры поддерживаются различными реализациями опционально, некоторые алгоритмы также обозначены как рекомендуемые (RECOMMENDED), это сделано для увеличения совместимости[6].

В протоколе 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
        }

DES-MAC OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3) //хранит длину MAC в битах как целое число,
           algorithm(2) 10                                     //ограниченное кратными 8, от 16 до 64
        }                

md5-DES-CBC OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) integrity(3) md5-DES-CBC(1)
        }

sum64-DES-CBC OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) integrity(3) sum64-DES-CBC(2)
        }

DES-CBC OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3)
           algorithm(2) 7 
        } 

RSAEncryption OBJECT IDENTIFIER ::= {
          iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 1        // заимствовано из PKCS#1 и RFC-1423
        }

dhKeyAgreement OBJECT IDENTIFIER ::= {
          iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
          pkcs-3(3) 1
       }

rightmost_k_bits ( OWF ( context_key || x || n || s || context_key ) )  где:

  MD5 OBJECT IDENTIFIER ::= {
          iso(1) member-body(2) US(840) rsadsi(113549)
          digestAlgorithm(2) 5
        }

  SHA OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3)
           algorithm(2) 18
        }

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

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

На представленной схеме инициатор соединения вызывает функцию gss_init_sec_context(), которая возвращает маркер SPKM_REQ, который затем пересылается приёмнику по используемому сетевому протоколу. Приёмник, получив этот маркер, передает его gss_accept_sec_context(), которая возвращает в качестве результата SPKM_REP_TI. Его приёмник отсылает обратно инициатору. Тот, в свою очередь, использует этот маркер, как входной параметр во время второго вызова gss_init_sec_context(). Если инициатором использовалась односторонняя аутентификация, то на этом установление соединения заканчивается. В противном случае (например, если изначально требуется взаимная аутентификация) gss_init_sec_context() возвращает SPKM_REP_IT, который посылается приёмнику. Тот использует этот маркер во время второго вызова gss_accept_sec_context() и, тем самым, завершает установку соединения. После этого, стороны могут обмениваться маркерами SPKM_MIC и SPKM_WRAP до тех пор, пока одна из сторон не пошлет SPKM_DEL для разрыва соединения[5].

Маркер SPKM_REQ содержит, среди других полей данных, следующие пункты:

• имена инициатора и приёмника
• новое (каждый раз разное) случайное число
• список доступных алгоритмов конфиденциальности (C-ALGs)
• список доступных алгоритмов целостности (I-ALGs)
• список доступных алгоритмов образования ключа (K-ALGs)
• ключ (или половина), соответствующие первого алгоритму образования ключа в представленном выше списке
• GSS опции соединения (такие как: односторонняя или взаимная аутентификация, использование последовательного и повторного обнаружения и так далее).

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

Маркер SPKM_REP_TI содержит:

• имена инициатора и приёмника
• случайное число, присланное инициатором
• новое случайное число
• подмножество предлагаемых алгоритмов конфиденциальности (C-ALGs), которые поддерживаются приёмником
• подмножество предлагаемых алгоритмов целостности (I-ALGs), которые поддерживаются приёмником
• альтернативный алгоритм образования ключа (K-ALG) из представленных в списке, если первый не подходит
• половина ключа, соответствующая алгоритму образования ключа инициатора или ключ (половина), соответствующий представленному выше алгоритму
• GSS опции.

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

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

• имена инициатора и приёмника
• случайное число, посланное инициатором в SPKM_REQ
• случайное число, посланное приёмником SPKM_REP_TI
• (при необходимости) половина ключа, соответствующая алгоритму образования ключа, выбранному приёмником.

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

По завершению установления соединения на основе случайных чисел, обе стороны аутентифицированы (без использования меток доверенного времени), ключ соединения был безопасно установлен, два набора алгоритмов (конфиденциальности и целостности) согласованы для использования в соединении операциями MIC и WRAP. Каждый SPKM_MIC, SPKM_WRAP, а также SPKM_DEL маркер может явно указывать соответствующий алгоритм из согласованного списка, который будет использоваться для данных, связанных с маркером, или же использовать алгоритмы «по умолчанию» (то есть первые алгоритмы в каждом из списков).

SPKM_MIC — используется для подписи и проверки целостности данных (gss_sign() / gss_getMIC())

SPKM_WRAP — используется для шифрования (расшифровки) и защиты конфиденциальности данных (gss_seal() / gss_wrap())

SPKM_DEL — для разрыва соединения (gss_delete_sec_context()).

Поэтому маркеры содержат следующую информацию:

• алгоритм целостности или «по умолчанию»
• алгоритм конфиденциальности «или по умолчанию» (только для SPKM_WRAP)
• порядковый номер
• контрольная сумма целостности (вычисляется из данных и представленной выше информации на основе представленного выше алгоритма целостности)
• входные данные (только для SPKM_WRAP).

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

Изначально были описаны две разновидности SPKM: SPKM-1 и SPKM-2, основным отличием, которых является то, что SPKM-2 требует наличие меток доверенного времени с целью повторного обнаружения во время установления соединения, а в SPKM-1 не требует. Это обеспечивает большую гибкость для приложений, так как в системе не всегда возможно использование меток доверенного времени. При создании в 2000 году протокола NFSv4 возникла необходимость в механизме, предусматривающем создание защищенного канала со взаимной аутентификацией, где:

1. Как пользователи, так и сервер проводят аутентификацию с использованием сертификатов открытого ключа
2. Сервер устанавливает подлинность по сертификатам открытого ключа, а пользователи по логину и паролю.
3. Клиент остается анонимным, а сервер использует сертификаты открытого ключа.

Так появился SPKM-3, который, используя надстройку LIPKEY, лежит в основе работы сетевых файловых систем[8][9]. В первую очередь он создан для упрощения процедуры аутентификации. Рассмотрим подробнее этот механизм.

Клиент:

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

Таким образом, между клиентом и сервером установлено защищенное соединение, как видно здесь применяется алгоритм Диффи — Хеллмана. Клиент может предоставить свой логин и пароль для аутентификации (или же сертификаты), однако, это не является обязательным, то есть клиент может оставаться анонимным.

Как видно, используемый механизм аутентификации аналогичен TLS, но вместе с простотой и удобством он также унаследовал и главный недостаток — возможность атаки человек посередине[10].

GSS-API (англ. Generic Security Service - Application Programming Interface — служба общей безопасности — интерфейс программирования приложений) позволяет приложению аутентифицировать пользователя, соответствующего другому приложению, с целью предоставления ему прав, и применить службы безопасности конфиденциальности и целостности данных для каждого сообщения.

Существует 4 этапа использования GSS-API:

1. Приложение получает ряд удостоверений, с помощью которых оно может доказать свою подлинность другим процессам. При этом удостоверение приложения отвечает глобальной учётной записи, которая может быть, и не связана с локальной.
2. С помощью своих удостоверений пара общающихся приложений устанавливает безопасное соединение, которое представляет собой пару структур данных GSS-API содержащих общую информацию состояния. Эта информация необходима для того чтобы обеспечить применение служб безопасности для каждого сообщения. В качестве этой информации могут выступать криптографические ключи и порядковые номера сообщений. В процессе установления безопасного соединения, инициатор этого соединения должен быть аутентифицирован другой стороной (приёмником), и также может требовать аутентификации приёмника. Инициатор может отдать приёмнику право инициировать безопасные соединения на своих правах, что возможно, если создать ряд удостоверений схожих с удостоверениями инициатора, с тем отличием что их может использовать приёмник. Для того чтобы создать и поддерживать общую информацию, обуславливающую безопасное соединение, определенные GSS-API вызовы возвращают метку структуры данных, которая содержит криптографически защищенные данные. Метка передается в соответствии с выбранным сетевым протоколом и, приняв её, удаленное приложение извлекает необходимую информацию и обновляет состояние безопасного соединения.
3. Для каждого сообщения службы безопасности направлены либо на обеспечение целостности данных и проверки их происхождения, либо ещё и на обеспечение конфиденциальности. При этом данные приложения рассматриваются GSS-API как случайные 8-символьные строки. При передаче сообщения, нуждающегося в защите, приложение вызывает соответствующую GSS-API функцию (например, gss_wrap()), указывая используемое соединение, и посылает полученную метку принимающей стороне. Та в свою очередь передает эту метку соответствующей функции расшифровки и получает исходное сообщение.
4. При завершении сессии обе стороны вызывают функцию разрыва соединения.

• http://www.ietf.org/rfc/rfc1508.txt
• http://www.ietf.org/rfc/rfc1509.txt
• http://www.ietf.org/rfc/rfc1510.txt
• http://www.ietf.org/rfc/rfc2025.txt
• http://www.ietf.org/rfc/rfc2847.txt
• http://www.ietf.org/rfc/rfc3530.txt
• https://www.ietf.org/mailman/listinfo/spkm
• http://potaroo.net/ietf/idref/draft-adamson-nfsv4-spkm3/#ref-RFC3280
• http://tools.ietf.org/html/draft-adamson-rfc2847-bis-01