Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Java PKCS#11 Справочник

1.0 Введение

2.0 Sun PKCS#11 Провайдер

2.1 Требования

2.2 Конфигурация

2.3 Доступ к Службам сетевой безопасности (NSS)

3.0 Разработчики приложений

3.1 Маркерный Вход в систему

3.2 Маркерные Ключи

3.3 Задержанный Выбор Провайдера

3.4 JAAS KeyStoreLoginModule

3.5 Маркеры как JSSE Keystores и Базы доверенных сертификатов

4.0 Инструменты

4.1 KeyTool и JarSigner

4.2 PolicyTool

5.0 Разработчики провайдера

5.1 Службы провайдера

5.1.1 Инстанцирование Классов Механизма

5.1.2 Поддержка параметра

Приложение Sun PKCS#11 Поддерживаемые Алгоритмы Провайдера

Приложение B Sun PKCS#11 Ограничения KeyStore Провайдера

Провайдер приложения C В качестве примера

1.0 Введение

Платформа Java определяет ряд интерфейсов программирования для того, чтобы выполнить криптографические операции. Эти интерфейсы все вместе известны как Архитектура Криптографии Java (JCA) и Расширение Криптографии Java (JCE). Спецификации доступны в Java страница Документации Безопасности SE.

Криптографические интерфейсы основаны на провайдере. Определенно, приложения говорят с Прикладными программными интерфейсами (API), и фактические криптографические операции выполняются в сконфигурированных провайдерах, которые придерживаются ряда Интерфейсов Поставщика услуг (SPI). Эта архитектура поддерживает различные реализации провайдера. Некоторые провайдеры могут выполнить криптографические операции в программном обеспечении; другие могут выполнить операции на аппаратном маркере (например на smartcard устройстве или на аппаратных средствах криптографический акселератор).

Криптографический Маркерный Стандарт Интерфейса, PKCS#11, производится Безопасностью RSA и определяет собственные интерфейсы программирования к криптографическим маркерам, таким как аппаратные средства криптографические акселераторы и Smartcards. Чтобы облегчить интеграцию собственных PKCS#11 маркеры в платформу Java, новый криптографический провайдер, Sun PKCS#11 провайдер, был введен в J2SE 5.0 выпусков. Этот новый провайдер позволяет существующим приложениям, записанным JCA и API JCE получить доступ собственный PKCS#11 маркеры. Никакие модификации к приложению не требуются. Единственное требование является надлежащей конфигурацией провайдера в Среду выполнения Java.

Хотя приложение может использовать большинство PKCS#11 функции, используя существующие API, некоторым приложениям, возможно, понадобились бы больше гибкости и возможностей. Например, приложение могло бы хотеть иметь дело с Smartcards, удаляемым и введенным динамически более легко. Или, PKCS#11 маркер мог бы потребовать, чтобы аутентификация для некоторых не манипулировала связанные операции и поэтому, приложение должно быть в состоянии зарегистрировать в маркер, не используя keystore. В J2SE 5.0, JCA был улучшен, чтобы позволить приложениям большую гибкость имея дело с различными провайдерами.

Этот документ описывает, как собственный PKCS#11 маркеры могут быть сконфигурированы в платформу Java для использования приложениями Java. Это также описывает улучшения, которые были сделаны к JCA облегчить для приложений иметь дело с различными типами провайдеров, включая PKCS#11 провайдеры.

2.0 Sun PKCS#11 Провайдер

Sun PKCS#11 провайдер, в отличие от большинства других провайдеров, не реализует криптографические алгоритмы самостоятельно. Вместо этого это действует как мост между Java JCA и API JCE и собственным PKCS#11 криптографический API, преобразовывая вызовы и соглашения между двумя. Это означает, что приложения Java, вызывая стандартный JCA и API JCE, без модификации, могут использовать в своих интересах алгоритмы, предлагаемые базовым PKCS#11 реализации, такой как, например,

• Криптографический Smartcards,
• Аппаратные средства криптографические акселераторы, и
• Высокопроизводительные реализации программного обеспечения.

2.1 Требования

Sun PKCS#11 провайдер требует реализации PKCS#11 v2.0 или позже быть установленным на системе. Эта реализация должна принять форму совместно используемой библиотеки объектов (.so на Солярисе и Linux) или динамически подключаемая библиотека (.dll на Windows). Пожалуйста, консультируйтесь со своей документацией поставщика, чтобы узнать, включает ли Ваше криптографическое устройство такой PKCS#11 реализация, как сконфигурировать это, и каково имя файла библиотеки.

Sun PKCS#11 провайдер поддерживает много алгоритмов, при условии, что базовое PKCS#11 реализация предлагает им. Алгоритмы и их соответствие PKCS#11 механизмы перечисляются в таблице в Приложении A.

2.2 Конфигурация

# configuration for security providers 1-6 ommitted
security.provider.7=sun.security.pkcs11.SunPKCS11 /opt/bar/cfg/pkcs11.cfg

String configName = "/opt/bar/cfg/pkcs11.cfg";
Provider p = new sun.security.pkcs11.SunPKCS11(configName);
Security.addProvider(p);

Чтобы использовать больше чем один слот на PKCS#11 реализация, или использовать больше чем один PKCS#11 реализация, просто повторяют установку для каждого с соответствующим конфигурационным файлом. Это приведет к Sun PKCS#11 экземпляр провайдера для каждого слота каждого PKCS#11 реализация.

Конфигурационный файл является текстовым файлом, который содержит записи в следующем формате.

name = FooAccelerator
library = /opt/foo/lib/libpkcs11.so

enabledMechanisms = {
  CKM_RSA_PKCS
  CKM_RSA_PKCS_KEY_PAIR_GEN
}

Конфигурация атрибутов

Опция attributes может использоваться, если Вам не нравятся значения по умолчанию Ваш PKCS#11, реализация присваивается или если Ваш PKCS#11 реализация не поддерживает значения по умолчанию и требует, чтобы значение было определено явно. Отметьте, что определение атрибутов, что Ваш PKCS#11 реализация не поддерживает или которые недопустимы для типа рассматриваемого ключа, может заставить работу перестать работать во время выполнения.

Опция может быть определена нуль или больше раз, опции обрабатываются в порядке, определенном в конфигурационном файле как описано ниже. У опции attributes есть формат:

attributes(operation, keytype, keyalgorithm) = {
  name1 = value1
  [...]
}

• generate, для ключей, сгенерированных через KeyPairGenerator или KeyGenerator
• import, для ключей, создаваемых через KeyFactory или SecretKeyFactory. Это также применяется к ключам программного обеспечения Java, автоматически преобразованным в PKCS#11 ключевые объекты, когда их передают к методу инициализации криптографической работы, например Signature.initSign().
• *, для ключей, создаваемых, используя или генерирование или создать работа.

Допустимые значения для keyalgorithm являются одной из констант CKK_xxx от PKCS#11 спецификация, или *, чтобы соответствовать ключи любого алгоритма. Алгоритмы, в настоящий момент поддерживаемые провайдером SunPKCS11, являются CKK_RSA, CKK_DSA, CKK_DH, CKK_AES, CKK_DES, CKK_DES3, CKK_RC4, CKK_BLOWFISH, и CKK_GENERIC.

Названия атрибута и значения определяются как список одной или более пар значение-имя. name должен быть CKA_xxx, постоянный от PKCS#11 спецификация, например CKA_SENSITIVE. value может быть одним из следующего:

• булево значение, true или false
• целое число, в десятичной форме (значение по умолчанию) или в шестнадцатеричной форме, если это начинается с 0x.
• null, указывая, что этот атрибут не должен быть определен, создавая объекты.

attributes(*,CKO_PRIVATE_KEY,*) = {
  CKA_SIGN = true
}

attributes(*,CKO_PRIVATE_KEY,CKK_DH) = {
  CKA_SIGN = null
}

attributes(*,CKO_PRIVATE_KEY,CKK_RSA) = {
  CKA_DECRYPT = true
}

Есть также специальная форма опции attributes. Можно записать attributes = compatibility в конфигурационном файле. Это - ярлык для целого набора операторов атрибута. Они разрабатываются к совместимости максимума провайдера с существующими приложениями Java, которые могут ожидать, например, что все ключевые компоненты будут доступными и секретными ключами, чтобы быть применимыми и для шифрования и для дешифрования. Строка атрибутов compatibility может использоваться вместе с другими строками attributes, когда та же самая агрегация и переопределяющие правила применяются как описано ранее.

2.3 Доступ к Службам сетевой безопасности (NSS)

Службы сетевой безопасности (NSS) являются рядом библиотек безопасности с открытым исходным кодом, пользовавшихся браузерами Mozilla/Firefox, программным обеспечением сервера Корпоративной системы Java Sun, и многими другими продуктами. Его crypto API основаны на PKCS#11, но это включает специальные функции, которые являются за пределами PKCS#11 стандарт. Sun PKCS#11 провайдер включает код, чтобы взаимодействовать с этими определенными функциями NSS, включая несколько определенных конфигурационных директив NSS, которые описываются ниже.

Для лучших результатов мы рекомендуем, чтобы Вы использовали последнюю версию доступного NSS. Это должна быть, по крайней мере, версия 3.11.1.

Sun PKCS#11 провайдер использует определенный код NSS когда любой из nss конфигурационные директивы, описанные ниже, используются. В этом случае, регулярные команды конфигурации library, slot, и slotListIndex не может использоваться.

Пример конфигурационные файлы SunPKCS11 для NSS

NSS как чистый провайдер криптографии

name = NSScrypto
nssLibraryDirectory = /opt/tests/nss/lib
nssDbMode = noDb
attributes = compatibility

NSS как FIPS 140 совместимых crypto маркеров:

name = NSSfips
nssLibraryDirectory = /opt/tests/nss/lib
nssSecmodDirectory = /opt/tests/nss/fipsdb
nssModule = fips

3.0 Разработчики приложений

Приложения Java могут использовать существующий JCA и API JCE к доступу PKCS#11 маркеры через Sun PKCS#11 провайдер. Это достаточно для многих приложений, но для приложения могло бы быть трудно иметь дело с определенным PKCS#11 функции, такие как неизвлекаемые ключи и динамически изменяющийся Smartcards. Следовательно, много улучшений были сделаны к API лучше поддерживать приложения, использующие бесспорный PKCS#11 функции. Эти enhancments обсуждаются в этом разделе.

3.1 Маркерный Вход в систему

Бесспорный PKCS#11 операции, такие как доступ к закрытым ключам, требуют входа в систему, используя Персональный идентификационный номер, или ПИН, прежде, чем операции смогут продолжиться. Наиболее распространенный тип операций, которые требуют входа в систему, является теми, которые имеют дело с, включает маркер. В приложении Java такие операции часто включают сначала загрузку keystore. Получая доступ PKCS#11 маркер как keystore через класс java.security.KeyStore, можно предоставить ПИН во входном параметре пароля к методу загрузки, подобному тому, как приложения инициализируют keystore до J2SE 5.0. ПИН будет тогда использоваться Sun PKCS#11 провайдер для того, чтобы зарегистрировать в маркер. Вот пример.

char[] pin = ...; 
KeyStore ks = KeyStore.getInstance("PKCS11");
ks.load(null, pin); 

Это прекрасно для приложения, которое обрабатывает PKCS#11 маркеры как статический keystores. Для приложения, которое хочет разместить PKCS#11 маркеры более динамически, такие как Smartcards, вводимый и удаленный, можно использовать новый класс KeyStore.Builder. Вот пример того, как инициализировать разработчика для PKCS#11 keystore с обработчиком обратного вызова.

KeyStore.CallbackHandlerProtection chp =
    new KeyStore.CallbackHandlerProtection(new MyGuiCallbackHandler());
KeyStore.Builder builder =
    KeyStore.Builder.newInstance("PKCS11", null, chp);

Для Sun PKCS#11 провайдер, обработчик обратного вызова должен быть в состоянии удовлетворить PasswordCallback, который используется, чтобы запросить пользователя ПИН. Всякий раз, когда приложение нуждается в доступе к keystore, это использует разработчика следующим образом.

KeyStore ks = builder.getKeyStore();
Key key = ks.getKey(alias, null);

Разработчик запросит пароль как необходимый использование ранее сконфигурированного обработчика обратного вызова. Разработчик запросит пароль только для начального доступа. Если пользователь приложения будет продолжать использовать тот же самый Smartcard, то пользователь не будет запрошен снова. Если пользователь удалит и введет различный SmartCard, то разработчик запросит пароль для новой карты.

В зависимости от PKCS#11 маркер, могут быть не ключевые связанные операции, которые также требуют маркерного входа в систему. Приложения, которые используют такие операции, могут использовать недавно представленный класс java.security.AuthProvider. Класс AuthProvider расширяется от java.security.Provider и определяет методы, чтобы выполнить операции входа в систему и выхода из системы на провайдере, так же как установить обработчик обратного вызова для провайдера, чтобы использовать.

Для Sun PKCS#11 провайдер, обработчик обратного вызова должен быть в состоянии удовлетворить PasswordCallback, который используется, чтобы запросить пользователя ПИН.

Вот пример того, как приложение могло бы использовать AuthProvider, чтобы зарегистрировать в маркер.

AuthProvider aprov = (AuthProvider)Security.getProvider("SunPKCS11");
aprov.login(subject, new MyGuiCallbackHandler());

3.2 Маркерные Ключи

Java Key объекты могут или, возможно, не содержат фактический ключевой материал.

• Ключевой объект программного обеспечения действительно содержит фактический ключевой материал и предоставляет доступ к тому материалу.
• Неизвлекаемый ключ на безопасном маркере (таком как Smartcard) представляется Ключевым объектом Java, который не содержит фактический ключевой материал. Ключевой объект только содержит ссылку на фактический ключ.

Приложения и провайдеры должны использовать корректные интерфейсы, чтобы представить эти различные типы Ключевых объектов. Ключевые объекты программного обеспечения (или любой Ключевой объект, у которого есть доступ к фактическому ключевому материалу) должны реализовать интерфейсы в java.security.interfaces и javax.crypto.interfaces пакетах (таких как DSAPrivateKey). Ключевые объекты, представляющие неизвлекаемые маркерные ключи, должны только реализовать соответствующие универсальные интерфейсы в java.security и javax.crypto пакетах (PrivateKey, PublicKey, или SecretKey). Идентификация алгоритма ключа должна быть выполнена, используя метод Key.getAlgorithm().

Приложения должны отметить, что Ключевой объект для неизвлекаемого маркерного ключа может только использоваться провайдером, связанным с тем маркером.

3.3 Задержанный Выбор Провайдера

До J2SE 5.0, методы getInstance() криптографии Java, такие как Cipher.getInstance("DES"), возвратили реализацию из первого провайдера, который реализовывал требуемый алгоритм. Это проблематично, если приложение пытается использовать объект Key для неизвлекаемого маркерного ключа с провайдером, который только принимает ключевые объекты программного обеспечения. В таком случае провайдер бросил бы InvalidKeyException. Это - проблема для Cipher, KeyAgreement, Mac, и классов Signature.

J2SE 5.0, решает эту проблему, задерживая выбор провайдера, пока соответствующий метод инициализации не вызывают. Метод инициализации принимает объект Key и может определить в той точке, какой провайдер может принять указанный объект Key. Это гарантирует, что выбранный провайдер может использовать указанный объект Key. Следующее представляет методы инициализации, на которые влияют.

• Cipher.init(..., Key key, ...)
• KeyAgreement.init(Key key, ...)
• Mac.init(Key key, ...)
• Signature.initSign(PrivateKey privateKey)

Хотя этот задержанный выбор провайдера скрывается от приложения, он действительно влияет на поведение getProvider() метод для Cipher, KeyAgreement, Mac, и Signature. Если getProvider() вызывается прежде, чем работа инициализации произошла (и поэтому прежде, чем выбор провайдера произошел), тогда первый провайдер, который поддерживает требуемый алгоритм, возвращается. Это, возможно, не тот же самый провайдер как то, выбранное после того, как метод инициализации вызывают. Если getProvider() вызывается после того, как работа инициализации произошла, тогда фактический выбранный провайдер возвращается. Этому рекомендуют это, приложения только вызывают getProvider() после того, как они вызвали соответствующий метод инициализации.

В дополнение к getProvider(), на следующие дополнительные методы так же влияют.

• Cipher.getBlockSize
• Cipher.getExcemptionMechanism
• Cipher.getIV
• Cipher.getOutputSize
• Cipher.getParameters
• Mac.getMacLength
• Signature.getParameters
• Signature.setParameter

3.4 JAAS KeyStoreLoginModule

Используйте следующие опции, чтобы сконфигурировать KeyStoreLoginModule, чтобы использовать PKCS#11 маркер как keystore.

• keyStoreURL="NONE"
• keyStoreType="PKCS11"
• keyStorePasswordURL=some_pin_url

other {
    com.sun.security.auth.module.KeyStoreLoginModule required
        keyStoreURL="NONE"
  keyStoreType="PKCS11"
  keyStorePasswordURL="file:/home/joe/scpin";
};

Если больше чем один Sun PKCS#11 провайдер был сконфигурирован динамически или в файле свойств безопасности java.security, можно использовать опцию keyStoreProvider, чтобы предназначаться для определенного экземпляра провайдера. Параметром этой опции является имя провайдера. Для Sun PKCS#11 провайдер, имя провайдера имеет форму SunPKCS11-TokenName, где TokenName является суффиксом имени, что экземпляр провайдера был сконфигурирован с, как детализировано в таблице атрибутов конфигурации. Например, следующий конфигурационный файл называет PKCS#11, экземпляр провайдера с именем снабжает суффиксом SmartCard.

other {
    com.sun.security.auth.module.KeyStoreLoginModule required
        keyStoreURL="NONE"
  keyStoreType="PKCS11"
  keyStorePasswordURL="file:/home/joe/scpin"
  keyStoreProvider="SunPKCS11-SmartCard";
};

Некоторые PKCS#11 маркеры поддерживают вход в систему через защищенный путь аутентификации. Например, у Smartcard может быть выделенная клавиатура ПИН, чтобы ввести контакт. У биометрических устройств также будут свои средства собственного получить информацию об аутентификации. Если PKCS#11 у маркера есть защищенный путь аутентификации, то используйте опцию protected=true и опустите опцию keyStorePasswordURL. Вот пример конфигурационного файла для такого маркера.

other {
    com.sun.security.auth.module.KeyStoreLoginModule required
        keyStoreURL="NONE"
  keyStoreType="PKCS11"
  protected=true;
};

3.5 Маркеры как JSSE Keystore и Базы доверенных сертификатов

JSSE также поддерживает конфигурирование использования keystores и баз доверенных сертификатов через системные свойства, как описано в Справочнике JSSE. Чтобы использовать PKCS#11 маркер как keystore или база доверенных сертификатов, установите javax.net.ssl.keyStoreType и системные свойства javax.net.ssl.trustStoreType, соответственно, к "PKCS11", и установите javax.net.ssl.keyStore и системные свойства javax.net.ssl.trustStore, соответственно, к NONE. Чтобы определить использование определенного экземпляра провайдера, используйте javax.net.ssl.keyStoreProvider и системные свойства javax.net.ssl.trustStoreProvider (например, "SunPKCS11-SmartCard").

4.0 Инструменты

В J2SE 5.0, средства обеспечения безопасности были обновлены, чтобы поддерживать операции, используя новый Sun PKCS#11 провайдер. Изменения обсуждаются ниже.

4.1 KeyTool и JarSigner

Если Sun PKCS#11 провайдер был сконфигурирован в файле свойств безопасности java.security (расположенный в каталоге $JAVA_HOME/lib/security Среды выполнения Java), то keytool и jarsigner могут использоваться, чтобы работать на PKCS#11 маркер, определяя следующие опции.

• -keystore НИ ОДИН
• -storetype PKCS11

keytool -keystore NONE -storetype PKCS11 -list

Если больше чем один Sun PKCS#11 провайдер был сконфигурирован в файле свойств безопасности java.security, можно использовать опцию -providerName, чтобы предназначаться для определенного экземпляра провайдера. Параметром этой опции является имя провайдера.

• -providerName providerName

keytool -keystore NONE -storetype PKCS11 \
        -providerName SunPKCS11-SmartCard \
        -list

Если Sun PKCS#11 провайдер не был сконфигурирован в файле свойств безопасности java.security, можно использовать следующие опции, чтобы дать команду keytool и jarsigner устанавливать провайдера динамически.

• Солнце security.pkcs11-providerClass. SunPKCS11
• -providerArg ConfigFilePath

keytool -keystore NONE -storetype PKCS11 \
        -providerClass sun.security.pkcs11.SunPKCS11 \
        -providerArg /foo/bar/token.config \
        -list

4.2 PolicyTool

До J2SE 5.0, у keystore записи в реализации политики по умолчанию был следующий синтаксис.

keystore "some_keystore_url", "keystore_type";

keystore "some_keystore_url", "keystore_type", "keystore_provider";
keystorePasswordURL "some_password_url";

Следующее является примером keystore запись политики для PKCS#11 маркер.

keystore "NONE", "PKCS11", "SunPKCS11-SmartCard";
keystorePasswordURL "file:/foo/bar/passwordFile";

5.0 Разработчики провайдера

J2SE 5.0 представляет новые средства в java.security. Класс провайдера для реализаций провайдера, чтобы более легко поддерживать PKCS#11 маркеры и криптографические службы вообще. Эти новые средства обсуждаются ниже.

См. Приложение C для примера простого провайдера, разработанного, чтобы демонстрировать новый facilties.

5.1 Службы провайдера

Как описано в вышеупомянутой документации провайдера, до J2SE 5.0, провайдеры были обязаны создавать записи java.util.Property, описывающие службы, которые они поддерживали. Для каждой службы, реализованной провайдером, должно быть свойство, имя которого является типом службы (Cipher, Signature, и т.д.), сопровождаемый периодом и именем алгоритма, к которому применяется служба. Значение свойства должно определить полностью определенное имя класса, реализовывая службу. Вот пример свойства установки KeyAgreement.DiffieHellman провайдера, чтобы иметь значение com.sun.crypto.provider.DHKeyAgreement.

put("KeyAgreement.DiffieHellman", 
      "com.sun.crypto.provider.DHKeyAgreement")

J2SE 5.0 представляет новый общедоступный статический вложенный класс, Provider.Service, чтобы помочь лучше инкапсулировать свойства службы провайдера (включая ее тип, атрибуты, имя алгоритма, и псевдонимы алгоритма). Провайдеры могут инстанцировать объектов Provider.Service и зарегистрировать их, вызывая метод Provider.putService(). Это эквивалентно созданию записи Property и вызову метода Provider.put() (как был сделан до J2SE 5.0). Отметьте, что наследство записи Property, зарегистрированные через Provider.put, все еще поддерживается.

Вот пример провайдера, создающего объект Service с типом KeyAgreement, для алгоритма DiffieHellman, реализованного классом com.sun.crypto.provider.DHKeyAgreement.

Service s = new Service(this, "KeyAgreement", "DiffieHellman",
    "com.sun.crypto.provider.DHKeyAgreement", null, null);
putService(s);

Используя объекты Provider.Servicee вместо наследства записи Property обладает несколькими главными преимуществами. Одно преимущество - то, что это позволяет провайдеру иметь большую гибкость, инстанцируя классов механизма. Другое преимущество - то, что это позволяет провайдеру тестировать законность параметра. Эти функции обсуждаются подробно затем.

5.1.1 Инстанцирование Классов Механизма

До J2SE 5.0, платформа Криптографии Java, искавшая свойство провайдера для определенной службы и непосредственно инстанцированный, класс механизма зарегистрировался для того свойства. J2SE 5.0, имеет то же самое поведение по умолчанию, но позволяет провайдеру переопределять это поведение и инстанцировать класса механизма для требуемой службы непосредственно.

Чтобы переопределить поведение по умолчанию, провайдер переопределяет метод Provider.Service.newInstance(), чтобы добавить его потребительское поведение. Например, провайдер мог бы вызвать пользовательского конструктора, или мог бы выполнить инициализацию, используя информацию, не доступную вне провайдера (или которые только известны провайдером).

5.1.2 Поддержка параметра

Платформа Криптографии Java может делать попытку быстрой проверки, чтобы определить, может ли реализация службы провайдера использовать определенный приложением параметр. Чтобы выполнить эту быструю проверку, платформа вызывает Provider.Service.supportsParameter().

В J2SE 5.0, платформа полагается на этот быстрый тест во время задержанного выбора провайдера. Когда приложение вызывает метод инициализации и передает его объект Key, платформа спрашивает базового провайдера, поддерживает ли он объект, вызывая его метод Service.supportsParameter(). Если supportsParameter() возвраты false, платформа может сразу удалить того провайдера из рассмотрения. Если supportsParameter() возвраты true, платформа передает объект Key к реализации класса механизма инициализации того провайдера. Провайдер, который требует программного обеспечения объекты Key, должен переопределить этот метод, чтобы возвратиться false когда это - переданные ключи непрограммного обеспечения. Аналогично, провайдер для PKCS#11 маркер, который содержит неизвлекаемые ключи, должен только возвратиться true поскольку Key возражает, что создал, и которые поэтому соответствуют Key s на его соответствующем маркере.

Отметьте что реализация по умолчанию supportsParameter() возвраты true. Это позволяет существующим провайдерам работать без модификации. Однако, из-за этой снисходительной реализации по умолчанию, платформа должна быть подготовлена поймать исключения, выданные провайдерами, которые отклоняют объект Key в их реализациях класса механизма инициализации. Платформа обрабатывает эти случаи то же самое как тогда, когда supportsParameter() возвраты false.

Приложение A: Sun PKCS#11 Поддерживаемые Алгоритмы Провайдера

Для механизмов Эллиптической кривой SunPKCS11 будет только использовать ключи, которые используют namedCurve выбор как кодирующий для параметров и только позволяет несжатый формат точки. Sun PKCS#11 провайдер предполагает, что маркер поддерживает весь стандарт, названный доменными параметрами.

Приложение B: Sun PKCS#11 Требования KeyStore провайдера

Следующее описывает требования, помещенные Sun PKCS#11 реализация KeyStore Провайдера на базовом собственном PKCS#11 библиотека. Отметьте, что изменения могут быть произведены в будущих выпусках, чтобы максимизировать функциональную совместимость с так многими существующими PKCS#11 библиотеки насколько возможно.

Доступ только для чтения

Чтобы отобразить существующие объекты, хранившие на PKCS#11 маркер к записям KeyStore, Sun PKCS#11, реализация KeyStore Провайдера выполняет следующие операции.

1. Поиск всех объектов с закрытым ключом на маркере выполняется, вызывая C_FindObjects [Init|Final]. Поисковый шаблон включает следующие атрибуты:
   • CKA_TOKEN = истина
   • CKA_CLASS = CKO_PRIVATE_KEY
2. Поиск всех объектов сертификата на маркере выполняется, вызывая C_FindObjects [Init|Final]. Поисковый шаблон включает следующие атрибуты:
   • CKA_TOKEN = истина
   • CKA_CLASS = CKO_CERTIFICATE
3. Каждый объект с закрытым ключом является соответствующим с его соответствующим сертификатом, получая их соответствующие атрибуты CKA_ID. Соответствующая пара должна совместно использовать тот же самый уникальный CKA_ID.

   Для каждой пары соответствия цепочка сертификата создается следующим выпускающий-> подчиненный путь. От сертификата объекта конца вызов fo C_FindObjects [Init|Final] выполняется с поисковым шаблоном, который включает следующие атрибуты:

   • CKA_TOKEN = истина
   • CKA_CLASS = CKO_CERTIFICATE
   • CKA_SUBJECT = [DN выпускающего сертификата]

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

   Как только закрытый ключ и сертификат были соответствующими (и его созданная цепочка сертификата), информация хранится в записи с закрытым ключом со значением CKA_LABEL от сертификата объекта конца как псевдоним KeyStore.

   Если у сертификата объекта конца нет никакого CKA_LABEL, то псевдоним получается из CKA_ID. Если CKA_ID может быть решен состоять исключительно из печатаемых символов, то Строковый псевдоним создается, декодируя байты CKA_ID, используя набор символов UTF-8. Иначе, шестнадцатеричный Строковый псевдоним создается из байтов CKA_ID ("0xFFFF...", например).

   Если многократные сертификаты совместно используют тот же самый CKA_LABEL, то псевдоним получается из CKA_LABEL плюс выпускающий сертификата объекта конца и порядковый номер ("MyCert/CN=foobar/1234", например).

4. Каждый сертификат не часть записи с закрытым ключом (как сертификат объекта конца) проверяется, доверяют ли этому. Если атрибут CKA_TRUSTED является истиной, то KeyStore запись сертификата, которой доверяют, создается со значением CKA_LABEL как псевдоним KeyStore. Если у сертификата нет никакого CKA_LABEL, или если многократные сертификаты совместно используют тот же самый CKA_LABEL, то псевдоним получается как описано выше.

   Если атрибут CKA_TRUSTED не поддерживается тогда, никакие доверяемые записи сертификата не создаются.

5. Любой закрытый ключ или объект сертификата не часть записи с закрытым ключом или полагала, что запись сертификата игнорируется.
6. Поиск всех объектов секретного ключа на маркере выполняется, вызывая C_FindObjects [Init|Final]. Поисковый шаблон включает следующие атрибуты:
   • CKA_TOKEN = истина
   • CKA_CLASS = CKO_SECRET_KEY

   Запись секретного ключа KeyStore создается для каждого объекта секретного ключа со значением CKA_LABEL как псевдоним KeyStore. У каждого объекта секретного ключа должен быть уникальный CKA_LABEL.

Доступ для записи

Чтобы создать новые записи KeyStore на PKCS#11 маркер к записям KeyStore, Sun PKCS#11, реализация KeyStore Провайдера выполняет следующие операции.

1. Создавая запись KeyStore (во время KeyStore.setEntry, например), C_CreateObject вызывают с CKA_TOKEN=true, чтобы создать маркерные объекты для соответствующего содержания записи.

   Объекты с закрытым ключом хранятся с CKA_PRIVATE=true. (UTF8-закодированный) псевдоним KeyStore устанавливается как CKA_ID и для закрытого ключа и для соответствующего сертификата объекта конца. Псевдоним KeyStore также устанавливается как CKA_LABEL для объекта сертификата объекта конца.

   Каждый сертификат в цепочке записи с закрытым ключом также сохранен. CKA_LABEL не устанавливается для сертификатов CA. Если сертификат CA уже находится в маркере, копия не сохранена.

   Объекты секретного ключа хранятся с CKA_PRIVATE=true. Псевдоним KeyStore устанавливается как CKA_LABEL.

2. Если попытка предпринимается, чтобы преобразовать объект сеанса в маркерный объект (например, если KeyStore.setEntry вызывают, и объект с закрытым ключом в указанной записи является сеансом ojbect), то C_CopyObject вызывают с CKA_TOKEN=true.
3. Если многократные сертификаты в маркере, как находят, совместно используют тот же самый CKA_LABEL, то возможности записи к маркеру отключаются.
4. Начиная с PKCS#11 спецификация не позволяет регулярным приложениям устанавливать CKA_TRUSTED=true (только маркерные приложения инициализации могут сделать так), доверяемые записи сертификата не могут быть созданы.

Разное

В дополнение к упомянутым выше поискам следующие поиски могут использоваться Sun PKCS#11 реализация KeyStore провайдера, чтобы выполнить внутренние функции. Определенно, C_FindObjects [Init|Final] можно вызвать с любым из следующих шаблонов атрибута:

•     CKA_TOKEN    true
      CKA_CLASS    CKO_CERTIFICATE
      CKA_SUBJECT  [subject DN]
      
  

•     CKA_TOKEN    true
      CKA_CLASS    CKO_SECRET_KEY
      CKA_LABEL    [label]
      
  

•     CKA_TOKEN    true
      CKA_CLASS    CKO_CERTIFICATE or CKO_PRIVATE_KEY
      CKA_ID       [cka_id] 
      
  

Приложение C: Провайдер В качестве примера

package com.foo;

import java.io.*;
import java.lang.reflect.*;
import java.security.*;
import javax.crypto.*;

/**
 * Example provider that demonstrates some of the new API features.
 *
 *  . implement multiple different algorithms in a single class.
 *    Previously each algorithm needed to be implemented in a separate class
 *    (e.g. one for MD5, one for SHA-1, etc.)
 *
 *  . multiple concurrent instances of the provider frontend class each
 *    associated with a different backend.
 *
 *  . it uses "unextractable" keys and lets the framework know which key
 *    objects it can and cannot support
 *
 * Note that this is only a simple example provider designed to demonstrate
 * several of the new features.  It is not explicitly designed for efficiency.
 */
public final class ExampleProvider extends Provider {

    // reference to the crypto backend that implements all the algorithms
    final CryptoBackend cryptoBackend;

    public ExampleProvider(String name, CryptoBackend cryptoBackend) {
        super(name, 1.0, "JCA/JCE provider for " + name);
        this.cryptoBackend = cryptoBackend;
        // register the algorithms we support (MD5, SHA1, DES, and AES)
        putService(new MyService
            (this, "MessageDigest", "MD5", "com.foo.ExampleProvider$MyMessageDigest"));
        putService(new MyService
            (this, "MessageDigest", "SHA1", "com.foo.ExampleProvider$MyMessageDigest"));
        putService(new MyCipherService
            (this, "Cipher", "DES", "com.foo.ExampleProvider$MyCipher"));
        putService(new MyCipherService
            (this, "Cipher", "AES", "com.foo.ExampleProvider$MyCipher"));
    }

    // the API of our fictitious crypto backend
    static abstract class CryptoBackend {
        abstract byte[] digest(String algorithm, byte[] data);
        abstract byte[] encrypt(String algorithm, KeyHandle key, byte[] data);
        abstract byte[] decrypt(String algorithm, KeyHandle key, byte[] data);
        abstract KeyHandle createKey(String algorithm, byte[] keyData);
    }

    // the shell of the representation the crypto backend uses for keys
    private static final class KeyHandle {
        // fill in code
    }

    // we have our own ServiceDescription implementation that overrides newInstance()
    // that calls the (Provider, String) constructor instead of the no-args constructor
    private static class MyService extends Service {

        private static final Class[] paramTypes = {Provider.class, String.class};

        MyService(Provider provider, String type, String algorithm,
                String className) {
            super(provider, type, algorithm, className, null, null);
        }

        public Object newInstance(Object param) throws NoSuchAlgorithmException {
            try {
                // get the Class object for the implementation class
                Class clazz;
                Provider provider = getProvider();
                ClassLoader loader = provider.getClass().getClassLoader();
                if (loader == null) {
                    clazz = Class.forName(getClassName());
                } else {
                    clazz = loader.loadClass(getClassName());
                }
                // fetch the (Provider, String) constructor
                Constructor cons = clazz.getConstructor(paramTypes);
                // invoke constructor and return the SPI object
                Object obj = cons.newInstance(new Object[] {provider, getAlgorithm()});
                return obj;
            } catch (Exception e) {
                throw new NoSuchAlgorithmException("Could not instantiate service", e);
            }
        }
    }

    // custom ServiceDescription class for Cipher objects. See supportsParameter() below
    private static class MyCipherService extends MyService {
        MyCipherService(Provider provider, String type, String algorithm,
                String className) {
            super(provider, type, algorithm, className);
        }
        // we override supportsParameter() to let the framework know which
        // keys we can support. We support instances of MySecretKey, if they
        // are stored in our provider backend, plus SecretKeys with a RAW encoding.
        public boolean supportsParameter(Object obj) {
            if (obj instanceof SecretKey == false) {
                return false;
            }
            SecretKey key = (SecretKey)obj;
            if (key.getAlgorithm().equals(getAlgorithm()) == false) {
                return false;
            }
            if (key instanceof MySecretKey) {
                MySecretKey myKey = (MySecretKey)key;
                return myKey.provider == getProvider();
            } else {
                return "RAW".equals(key.getFormat());
            }
        }
    }

    // our generic MessageDigest implementation. It implements all digest
    // algorithms in a single class. We only implement the bare minimum
    // of MessageDigestSpi methods
    private static final class MyMessageDigest extends MessageDigestSpi {
        private final ExampleProvider provider;
        private final String algorithm;
        private ByteArrayOutputStream buffer;
        MyMessageDigest(Provider provider, String algorithm) {
            super();
            this.provider = (ExampleProvider)provider;
            this.algorithm = algorithm;
            engineReset();
        }
        protected void engineReset() {
            buffer = new ByteArrayOutputStream();
        }
        protected void engineUpdate(byte b) {
            buffer.write(b);
        }
        protected void engineUpdate(byte[] b, int ofs, int len) {
            buffer.write(b, ofs, len);
        }
        protected byte[] engineDigest() {
            byte[] data = buffer.toByteArray();
            byte[] digest = provider.cryptoBackend.digest(algorithm, data);
            engineReset();
            return digest;
        }
    }

    // our generic Cipher implementation, only partially complete. It implements
    // all cipher algorithms in a single class. We implement only as many of the
    // CipherSpi methods as required to show how it could work
    private static abstract class MyCipher extends CipherSpi {
        private final ExampleProvider provider;
        private final String algorithm;
        private int opmode;
        private MySecretKey myKey;
        private ByteArrayOutputStream buffer;
        MyCipher(Provider provider, String algorithm) {
            super();
            this.provider = (ExampleProvider)provider;
            this.algorithm = algorithm;
        }
        protected void engineInit(int opmode, Key key, SecureRandom random)
                throws InvalidKeyException {
            this.opmode = opmode;
            myKey = MySecretKey.getKey(provider, algorithm, key);
            if (myKey == null) {
                throw new InvalidKeyException();
            }
            buffer = new ByteArrayOutputStream();
        }
        protected byte[] engineUpdate(byte[] b, int ofs, int len) {
            buffer.write(b, ofs, len);
            return new byte[0];
        }
        protected int engineUpdate(byte[] b, int ofs, int len, byte[] out, int outOfs) {
            buffer.write(b, ofs, len);
            return 0;
        }
        protected byte[] engineDoFinal(byte[] b, int ofs, int len) {
            buffer.write(b, ofs, len);
            byte[] in = buffer.toByteArray();
            byte[] out;
            if (opmode == Cipher.ENCRYPT_MODE) {
                out = provider.cryptoBackend.encrypt(algorithm, myKey.handle, in);
            } else {
                out = provider.cryptoBackend.decrypt(algorithm, myKey.handle, in);
            }
            buffer = new ByteArrayOutputStream();
            return out;
        }
        // code for remaining CipherSpi methods goes here
    }

    // our SecretKey implementation. All our keys are stored in our crypto
    // backend, we only have an opaque handle available. There is no
    // encoded form of these keys.
    private static final class MySecretKey implements SecretKey {

        final String algorithm;
        final Provider provider;
        final KeyHandle handle;

        MySecretKey(Provider provider, String algorithm, KeyHandle handle) {
            super();
            this.provider = provider;
            this.algorithm = algorithm;
            this.handle = handle;
        }
        public String getAlgorithm() {
            return algorithm;
        }
        public String getFormat() {
            return null; // this key has no encoded form
        }
        public byte[] getEncoded() {
            return null; // this key has no encoded form
        }
        // Convert the given key to a key of the specified provider, if possible
        static MySecretKey getKey(ExampleProvider provider, String algorithm, Key key) {
            if (key instanceof SecretKey == false) {
                return null;
            }
            // algorithm name must match
            if (!key.getAlgorithm().equals(algorithm)) {
                return null;
            }
            // if key is already an instance of MySecretKey and is stored
            // on this provider, return it right away
            if (key instanceof MySecretKey) {
                MySecretKey myKey = (MySecretKey)key;
                if (myKey.provider == provider) {
                    return myKey;
                }
            }
            // otherwise, if the input key has a RAW encoding, convert it
            if (!"RAW".equals(key.getFormat())) {
                return null;
            }
            byte[] encoded = key.getEncoded();
            KeyHandle handle = provider.cryptoBackend.createKey(algorithm, encoded);
            return new MySecretKey(provider, algorithm, handle);
        }
    }
}

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами