- •2. Модели аппаратных ключей hasp hl
- •3. Охарактеризовать технологию защиты приложений с помощью утилиты hasp Envelope.
- •4. Охарактеризовать основные сервисы hasp, используемые при защите программ с использованием hasp api.
- •5. Обзор функций Hasp srm Run-time api
- •6. Основные сведения о типичной микропроцессорной карточке.
- •7. Методы защиты смарт-карт от подделки.
- •10. Структуры и типы команд по стандарту iso 7816-4
- •11. Виды ключей смарт-карт ase и работа с ними на уровне карты.
- •1. Персональный идентификационный номер (pin)
- •2. Главный ключ
- •3. Ключи доступа
- •4. Вычислительные ключи
- •12. Виды ключей смарт-карт ase и работа с ними на уровне приложений.
- •1. Персональный идентификационный номер (pin)
- •2. Главный ключ
- •3. Ключи доступа
- •4. Вычислительные ключи
- •13. Основные параметры функций asehlCreate File
- •14. Основные параметры функций asehlCreate App
- •15. Описание параметров File Properties
- •16. Назначение смарт-карт e-Token pro:
- •17. Основные характеристики eToken Pro
- •18.Четыре области памяти в смарт-картах eToken pro
- •20. Уровни доступа к информации в картах eToken
- •21. Архитектура программного обеспечения
- •22. Среда программирования eToken rte
- •27. Охарактеризовать 2 схемы аутентификации, использующиеся в современных вычислительных системах.
- •28. Охарактеризовать виды биометрической аутентификации
- •29. Поясните схему «запрос-ответ» при взаимной аутентификации.
- •30. Что такое «временной штемпель», как он используется при взаимной аутентификации.
- •31. Схема взаимной аутентификации с использованием рукопожатия.
- •32. Базовый протокол централизованного распределения ключей для симметричной криптосистемы.
- •33. Базовый протокол распределения ключей для асимметричных криптосистем с использованием сертификатов открытых ключей.
- •34. Структура сертификата по рекомендациям X.509.
- •35. Проверка сертификатов, в том числе полученных в разных удостоверяющих центрах.
- •36. Прямой обмен ключами между пользователями с использованием криптосистемы с открытым ключом для шифрования и передачи секретного ключа симметричной системы (электронный цифровой конверт).
- •37. Использование системы открытого распределения ключей Диффи-Хеллмана для формирования ключей.
- •38. Симметричные методы аутентификации субъекта. Схема Kerberos.
- •39. Аутентификация субъекта в асимметричных системах по стандарту ccitt Recommendation X.509.
- •40. Генерация ключей по стандарту ansi X 9.17.
- •41. Хранение ключей согласно iso 8532.
- •42. Мастер-ключ. Правила распространения и хранения.
- •43. Сеансовый ключ. Хранение
- •44. Методы обеспечения целостности. Режим выработки имитовставки гост 28147-89
- •45. Методы контроля целостности сообщений. Использование шифрования, эцп, кодов аутентификации сообщений, имитовставок,
- •47. Модели политики безопасности при построении защищенных систем
- •48. Алгоритм обработки битов защиты в unix.
- •49. Списки прав доступа acl.
- •50. Алгоритм обработки списков прав доступа (произвольное управление доступом) в Trusted Mach
- •51. В чем заключается полномочный (мандатный) способ доступа субъектов к объектам.
- •52. Мандатное управление доступом в мсвс 3.0
- •53. Аудит
22. Среда программирования eToken rte
eToken RTE — это набор необходимых программных компонентов для поддержки eToken в различных операционных системах и приложениях.
Интерфейсы, обеспечиваемые в eToken
PKCS #11;
CAPI;
SAPI.
23. PKCS#11
PKCS#11 (Public-Key Cryptography Standard) – стандарт криптографии с открытым ключом, разработанный лабораторией RSA. Это промышленный стандарт, определяющий технологичкески-независимый программный интерфейс для таких криптографических устройств как смарт-карты и PCMCIA карты.
Данный стандарт определяет application program interface (API), называемый Cryptoki (Cryptographic Token Interface) для устройств, как физических, так и виртуальных, которые содержат криптографическую информацию (ключи и прочие данные), а так же осуществляют криптографические функции.
Данный API используется на различных платформах и является достаточно мощным инструментом для создания приложений, направленных на обеспечение безопасности. Aladdin использует PKCS#11 как главный API для программирования eToken.
Вся определяемая поставщиком функциональность eToken доступна с помощью средств PKCS#11 API или разработанных на его основе расширений.
25. CAPI
CAPI (CryptoAPI) – это API, разработанный компанией Microsoft как часть Microsoft Windows. Предназначен он для использования разработчиками Windows-приложений. CAPI делает возможным сосуществование на одном персональном компьютере множества криптографических поставщиков услуг (cryptographic service providers – CSP), которые могут быть использованы одним и тем же приложением.
Кроме того существует возможность ассоциации CSP с конкретной смарт-картой таким образом, что работающие с ней Windows-приложения будут вызывать корректный CSP.
Выбор того, какой API использовать при разработке приложений, зависит от конкретного приложения. Здесь приведены лишь несколько советов:
PKCS#11 позволяет легко управлять сразу несколькими eToken. CAPI не имеет представления о физическом токене.
PKCS#11 имеет API (C_WaitForSlotEvent функцию), которая ждёт уведомления о подключении/удалении токена.
PKCS#11 позволяет сохранять на eToken оба ключа RSA, сертификаты и объекты данных, CAPI - лишь ключи RSA и соответствующие им сертификаты.
PKCS#11 не имеет вспомогательных функций для работы с сертификатами.
Большинство дополнительных функций и расширений предусмотрены в PKCS#11, eToken CAPI имеет очень маленький набор предусмотренных производителем расширений.
PKCS#11 – это API, а не архитектура. CAPI – это часть MS Windows.
CAPI имеет множество вспомогательных функций. Это позволяет программисту сконцентрировать своё внимание на логике работы приложения и избавляет его от необходимости иметь дело с низкоуровневыми деталями.
При всём этом важно отметить, что все CAPI объекты доступны при использовании PKCS#11 и наоборот. Тем не менее могут существовать некоторые ограничения, накладываемые на взаимодействие двух API, и настоятельно рекомендуется использовать в приложении лишь один из них.
26. SAPI
SAPI (Supplementary API) впервые применён в eToken RTE 3.60 с целью внедрения в приложения низкоуровневых API. Он предоставляет доступ к специфическим функциям eToken, не охваченным стандартом PKCS#11. SAPI поддерживается в PKI Client.
Поддерживаемые модели eToken.
PKI Client поддерживает несколько типов токенов:
eToken PRO (Siemens CardOS and Java card based);
eToken PRO Smartcard (Siemens CardOS and Java card based);
Token NG-OTP;
Token NG-FLASH;
eToken Virtual.
В дополнение PKI Client может быть использован для осуществления криптографических операций при отсутствии токена.