Power Security Support Wiki - Вклад участника [ru]

Сервер аутентификации

2016-08-09T13:22:33Z

Korabelnikov:

'''Сервер аутентификации''' (англ. '''Authentication Server''') – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент». Другой пример использования сервера аутентификации - [http://powersecurity.ru/ru/solutions/remote-access-to-corporate-resources/ удаленный доступ к корпоративным ресурсам], который компания дает своим пользователям или партнерам.

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

==Ключевые особенности==
*Поддержка различных моделей и типов генераторов одноразовых паролей
*Интеграция с сервисами
*Поддержка различных каналов аутентификации, методов аутентификации
*Безопасный доступ к серверу аутентификации
*Поддержка [[HSM]]-модулей
*Поддержка протокола RADIUS
*Поддержка стандартов OAuth 2.0, SAML 2.0

Использование [[строгая аутентификация |многофакторной аутентификации]] непременно снижает риски компрометации аутентификационных данных клиента. Применение [[одноразовый пароль |одноразовых паролей]] (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта [[OATH]] ([[TOTP]], [[HOTP]], [[OCRA]]) или [[EMV]], сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

''Пример:'' банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; [[HSM]]). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные [[HSM]] ([http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect Thales nShield], [http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/ SafeNet], [http://hsm.utimaco.com/products/ Utimaco], функционирующих в режиме FIPS).

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

Поддержка протокола SAML 2.0 позволяет быстро подключать веб-ресурсы, которые могут работать в режиме SAML Service Provider. Для [http://powersecurity.ru/ru/solutions/mobileapp-authentication/ аутентификации мобильных приложений] более удобным является использование стандатра OAuth 2.0.

==Примеры==
#[http://powersecurity.ru/ru/products/auth/nexus-hybrid-access-gateway/ neXus Hybrid Access Gateway]
#[http://powersecurity.ru/ru/products/auth/nexus-portwise/auth-server/ neXus Portwise Authentication Server]
#[http://powersecurity.ru/ru/products/auth/cryptomathic-authenticator/ Cryptomathic Authenticator]
#[http://www.hidglobal.com/identity-assurance# ActivID Security Solutions]
#[http://www.thales-esecurity.com/products-and-services/products-and-services/identity-management/authentication/safesign-authentication-server SafeSign Authentication Server]

Сервер аутентификации

2016-08-09T13:21:45Z

Korabelnikov:

'''Сервер аутентификации''' (англ. '''Authentication Server''') – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент». Другой пример использования сервера аутентификации - [http://powersecurity.ru/ru/solutions/remote-access-to-corporate-resources/ удаленный доступ к корпоративным ресурсам], который компания дает своим пользователям или партнерам.

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

==Ключевые особенности==
*Поддержка различных моделей и типов генераторов одноразовых паролей
*Интеграция с сервисами
*Поддержка различных каналов аутентификации, методов аутентификации
*Безопасный доступ к серверу аутентификации
*Поддержка [[HSM]]-модулей
*Поддержка протокола RADIUS
*Поддержка стандартов OAuth 2.0, SAML 2.0

Использование [[строгая аутентификация |многофакторной аутентификации]] непременно снижает риски компрометации аутентификационных данных клиента. Применение [[одноразовый пароль |одноразовых паролей]] (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта [[OATH]] ([[TOTP]], [[HOTP]], [[OCRA]]) или [[EMV]], сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

''Пример:'' банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; [[HSM]]). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные [[HSM]] ([http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect Thales nShield], [http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/ SafeNet], [http://hsm.utimaco.com/products/ Utimaco], функционирующих в режиме FIPS).

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

Поддержка протокола SAML 2.0 позволяет быстро подключать веб-ресурсы, которые могут работать в режиме SAML Service Provider. Для [http://powersecurity.ru/ru/solutions/mobileapp-authentication/Аутентификации мобильных приложений] более удобным является использование стандатра OAuth 2.0.

==Примеры==
#[http://powersecurity.ru/ru/products/auth/nexus-hybrid-access-gateway/ neXus Hybrid Access Gateway]
#[http://powersecurity.ru/ru/products/auth/nexus-portwise/auth-server/ neXus Portwise Authentication Server]
#[http://powersecurity.ru/ru/products/auth/cryptomathic-authenticator/ Cryptomathic Authenticator]
#[http://www.hidglobal.com/identity-assurance# ActivID Security Solutions]
#[http://www.thales-esecurity.com/products-and-services/products-and-services/identity-management/authentication/safesign-authentication-server SafeSign Authentication Server]

Сервер аутентификации

2016-08-09T13:14:46Z

Korabelnikov: /* Примеры */

'''Сервер аутентификации''' (англ. '''Authentication Server''') – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент».

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

==Ключевые особенности==
*Поддержка различных моделей и типов генераторов одноразовых паролей
*Интеграция с сервисами
*Поддержка различных каналов аутентификации, методов аутентификации
*Безопасный доступ к серверу аутентификации
*Поддержка [[HSM]]-модулей
*Поддержка протокола RADIUS
*Поддержка стандартов OAuth 2.0, SAML 2.0

Использование [[строгая аутентификация |многофакторной аутентификации]] непременно снижает риски компрометации аутентификационных данных клиента. Применение [[одноразовый пароль |одноразовых паролей]] (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта [[OATH]] ([[TOTP]], [[HOTP]], [[OCRA]]) или [[EMV]], сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

''Пример:'' банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; [[HSM]]). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные [[HSM]] ([http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect Thales nShield], [http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/ SafeNet], [http://hsm.utimaco.com/products/ Utimaco], функционирующих в режиме FIPS).

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

==Примеры==
#[http://powersecurity.ru/ru/products/auth/nexus-hybrid-access-gateway/ neXus Hybrid Access Gateway]
#[http://powersecurity.ru/ru/products/auth/nexus-portwise/auth-server/ neXus Portwise Authentication Server]
#[http://powersecurity.ru/ru/products/auth/cryptomathic-authenticator/ Cryptomathic Authenticator]
#[http://www.hidglobal.com/identity-assurance# ActivID Security Solutions]
#[http://www.thales-esecurity.com/products-and-services/products-and-services/identity-management/authentication/safesign-authentication-server SafeSign Authentication Server]

Сервер аутентификации

2016-08-09T13:12:30Z

Korabelnikov: /* Ключевые особенности */

'''Сервер аутентификации''' (англ. '''Authentication Server''') – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент».

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

==Ключевые особенности==
*Поддержка различных моделей и типов генераторов одноразовых паролей
*Интеграция с сервисами
*Поддержка различных каналов аутентификации, методов аутентификации
*Безопасный доступ к серверу аутентификации
*Поддержка [[HSM]]-модулей
*Поддержка протокола RADIUS
*Поддержка стандартов OAuth 2.0, SAML 2.0

Использование [[строгая аутентификация |многофакторной аутентификации]] непременно снижает риски компрометации аутентификационных данных клиента. Применение [[одноразовый пароль |одноразовых паролей]] (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта [[OATH]] ([[TOTP]], [[HOTP]], [[OCRA]]) или [[EMV]], сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

''Пример:'' банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; [[HSM]]). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные [[HSM]] ([http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect Thales nShield], [http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/ SafeNet], [http://hsm.utimaco.com/products/ Utimaco], функционирующих в режиме FIPS).

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

==Примеры==
#[http://powersecurity.ru/ru/products/auth/nexus-portwise/auth-server/ neXus Portwise Authentication Server]
#[http://www.hidglobal.com/identity-assurance# ActivID Security Solutions]
#[http://www.thales-esecurity.com/products-and-services/products-and-services/identity-management/authentication/safesign-authentication-server SafeSign Authentication Server]

2016-08-09T13:09:45Z

Korabelnikov:

PIN — Personal Identification Number, персональный идентификационный номер. В последнее время стал синонимом пароля, то есть некоторого секрета, используемого в процессе аутентификации. Используется как логический элемент [[строгая аутентификация|строгой аутентификации]].
Изначально PIN был только цифровым и имел короткую длину, как правило 4 цифры. Сейчас, PIN может содержать и буквы, и спецсимволы, его длина увеличилась.

==Типы PIN==

В контексте он-лайн безопасности можно выделить два типа PINов:
#Проверяемые устройством
#Проверяемые на сервере (сервер-проверяемые)

===PIN-код проверяемый устройством===

Это PIN, который проверяется непосредственно устройством. Примерами являются смарт-карты, чипованные EVM-карты, генераторы [[Одноразовый пароль|одноразовых паролей]] с клавиатурой.

===Проверяемые на сервере (сервер-проверяемые)===
Полный аналог пароля, вводится в окно аутентификации в специальное поле или в поле ввода одноразового пароля (до или после
него, зависит от сервера аутентификации) и проверяется [[сервер аутентификации|сервером аутентификации]], а не устройством, как в предыдущем случае.
У таких PIN есть существенный недостаток: он, как и любой другой статический секрет подвержен атакам «запись-воспроизведение».

HCE

2016-08-09T13:07:23Z

Korabelnikov: /* Существующие решения */

'''Host Card Emulation (HCE)''' – технология эмуляции смарт-карты на мобильном устройстве. Именно эта технология в совокупности с NFC позволяет осуществлять мобильные бесконтактные платежи без использования физического элемента безопасности (Secure Element).

==Введение==
Использование пластиковых карт давно уже стало общепринятым методом оплаты современных пользователей. Появление многофункциональных мобильных устройств (смартфонов, планшетов) и их широкое использование позволило расширить способы безналичной оплаты. Теперь у пользователя появится возможность осуществлять покупки с использованием своего «мобильного кошелька», находящегося в его смартфоне. Бесконтактные мобильные платежи должны происходить быстро, просто и безопасно между мобильным телефоном потребителя и торговым терминалом. Технология Near Field Communication ([[NFC]]) позволяет осуществлять подобные платежи и уже применяется во многих странах, в том числе и в России. На сегодняшний день [[NFC]] поддерживается большим количеством как бесконтактных карт, так и мобильных устройств.
Согласно отчету, опубликованному [http://www.juniper.net/ru/ru/ Juniper] в мае 2014 года, использование мобильных кошельков значительно увеличится к 2018 и составит около 1.5 миллиарда. Основной тенденцией для развития мобильных бесконтактных платежей является технология HCE, входящая в состав спецификации [[NFC]].

==О технологии NFC==

*[http://powersecurity.ru/ru/support/wiki/index.php?title=NFC Основная статья: NFC]

О технологии NFC. NFC – это технология бесконтактных коммуникаций небольшого радиуса, которая позволяет осуществлять взаимодействие между двумя устройствами на расстоянии не более 10 см. На основе данной технологии устройства (например, мобильные телефоны) могут взаимодействовать друг с другом по беспроводному каналу связи. Благодаря NFC и расширенным механизмам защиты стало возможным использовать «виртуальные» [http://powersecurity.ru/ru/support/wiki/index.php?title=%D0%A1%D0%BC%D0%B0%D1%80%D1%82-%D0%BA%D0%B0%D1%80%D1%82%D0%B0 смарт-карты] (эмуляция карты) на мобильных устройствах. Традиционно безопасность технологии эмуляции карты основывается на Secure Element (SE) – устойчивому ко взлому чипу, расположенному внутри устройства. SE может производить криптографические операции и хранить чувствительные данные в безопасной и доверенной среде. Большое количество компаний рассмотрели эту технологию в качестве возможности реализации мобильного кошелька: безналичная оплата в магазинах, программы лояльности, оплата проезда и другие варианты применения. Однако, реализация SE влечет за собой ряд трудностей. Secure Element может поставляться в нескольких вариантах, например: на SIM-карте мобильного оператора, на SD-карте или в качестве встроенного в телефон чипа. Все это в совокупности приводит к привязке к одному поставщику (например, SD-карты) и к необходимости взаимодействия операторов сотовой связи с производителями SE, что может повлечь дополнительные препятствия и накладные расходы.

==Появление идеи HCE==
Компания Google уже сталкивалась с подобными проблемами при выпуске своего мобильного кошелька на рынок. Причина в том, что многие мобильные операторы не позволили поисковому гиганту получить доступ к своему Secure Element, так как уже предоставили доступ для реализации решения конкурентному производителю.
В связи с такими препятствиями игроки этого рынка стали искать альтернативные подходы. Появление технологии HCE (Host-based Card Emulation) значительно исправила ситуацию. Эта технология была реализована на мобильных платформах [http://us.blackberry.com/ Blackberry 7] в 2011 году и позже, в конце 2013, года появилась в [http://www.kitkat.com/android/#/home Android KitKat 4.4]. Такие компании как [http://visa.com.ru/ru/ru-ru/index.shtml Visa] и [http://www.mastercard.com/index.html MasterCard] уже разрабатывают спецификации, ориентированные на бесконтактные мобильные платежи на основе HCE.

==Как работает HCE на примере ОС Android==
NFC имеет 3 режима работы: режим чтения/записи для чтения/записи данных на/с тэга (tag), «точка-точка» (Peer-to-Peer) для взаимодействия между двумя устройствами и режим эмуляции карты. NFC контроллер – чип, расположенный внутри устройства, принимающий решения о маршрутизации команд в зависимости от вышеописанных режимов. Если используется SE, то команды первых двух режимов направляются в процессор устройства, а третьего - в SE. В случае с HCE, команды режима эмуляции карты будут отправляться в сервис HCE на процессоре.
[[image:HCE_SE_phone.png|border|150px|thumb|right]]

==Безопасность HCE==
Когда речь идет о программной реализации «хранилища» данных карт, то появляются новые риски, которые в том числе могут быть связаны с самой мобильной ОС.
В HCE все запросы проходят через саму ОС Android. Это позволяет обеспечить базовыми механизмами защиты, например: каждое приложение запускается в отдельной «песочнице» (sandbox), благодаря чему доступ к данным других приложений становится невозможным. Однако, если получить полный доступ к телефону, т.е. права суперпользователя (root), то эти функции безопасности уже не работают. На базе данного факта можно заключить следующие уязвимости:
#'''Получение прав суперпользователя''' («рут» телефона). В этом случае пользователь получает доступ ко всей информации, хранящейся в приложении, включая конфиденциальную (например, платежи…).
#'''Вредоносное ПО'''. Для недавних версий ОС Android были выпущены эксплоиты, которым удавалось получить права суперпользователя через вредоносное приложение. Хотя данное приложение нельзя было скачать с официальных источников, все равно такая уязвимость является потенциальным риском, на который необходимо обращать внимание. Это доказало, что достаточно трудно определить уязвимости такого рода, так как обновление ОС занимает длительный процесс. На данный момент очень много устройств имеют старые версии 2.3.3-2.3.7.
#'''Потеря/кража телефона'''. Получив телефон, злоумышленник может также получить права пользователя, подключив это устройство к другому, таким образом, получить всю необходимую информацию и использовать ее для осуществления нелегитимных транзакций.
Поэтому, если говорить о реализации мобильного кошелька с использованием технологии HCE, необходимо прибегать к применению дополнительных методов защиты, чтобы избежать компрометации чувствительных данных. К таким методам можно отнести следующие: проверка операционной системы на наличие прав суперпользователя (root), шифрование данных криптографическими методами, обфускация кода приложения и др. Несмотря на то, что HCE появилась относительно недавно, многие компании уже предлагают решения на базе данной технологии, обеспечивая при этом высоким уровнем защиты и соответствующими механизмами безопасности, чтобы максимально снизить потенциально возникающие риски.

==Существующие решения==
Компании, которые занимаются разработкой мобильных платежных решений на базе технологии HCE:
*[http://www.seglan.com/ Seglan]
*[http://www.cryptomathic.com/solutions/mobile Cryptomathic]
*[http://www.wirecard.com/products/mobile-payment/payment-on-mobile/ WireCard]
* и другие.

==Источники==
*[http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications HCE Security Implications (UL)]
*[http://www.nfcworld.com/2014/05/20/329241/juniper-predicts-1-5bn-mobile-wallets-2018/ Juniper predicts 1.5bn mobile wallets in 2018 (Sarah Clark)]
*[http://blog.euromonitor.com/2014/03/could-hce-be-the-inflection-point-for-mobile-payments.html Could HCE be the Inflection Point for Mobile Payments? (Michelle Evans)]
*[http://www.diva-portal.org/smash/get/diva2:537698/FULLTEXT01.pdf Contactless mobile payments in Europe]

NFC

2016-08-09T13:06:47Z

Korabelnikov: /* NFC для бесконтактной оплаты */

'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций небольшого радиуса действия (на расстоянии нескольких сантиметров). NFC является расширением стандарта ISO/IEC 14443 (стандарт бесконтактных карт) и работает на частоте 13,56 MHz в соответствии с ISO/IEC 18000-3; позволяет передавать данные со скоростью от 106 до 424 кбит/с.

==Описание==
Требуется две стороны для передачи данных: инициатор и целевое устройство. Инициатор создаёт электромагнитное поле, благодаря которому целевое устройство получает питание.

NFC позволяет осуществлять не только одностороннюю связь, когда инициатор получает данные с целевого устройства (пассивный режим), но и двухстороннее общение (активный режим), для чего оба устройства должны обладать источником энергии.

==Стандартизация==
Обеспечением совместимости и разработкой спецификаций занимается ассоциация '''GSM Association''' ('''GSMA'''), состоящая из примерно 800 операторов мобильной связи и 200 других компаний.

Продвижением использования NFC в мобильных устройствах и бытовой электронике занимается организация '''NFC Forum'''.

'''[[EMV]]Co''' разрабатывает спецификации для осуществления бесконтактных платежей.

'''GlobalPlatform''' — некоммерческая ассоциация, разрабатывающая архитектуру элемента безопасности (Secure Element).

==Применения NFC в мобильных устройствах==
Технология NFC находит большое количество применений в разных сферах, например:
*передача данных
*банковские платёжные карты
*транспортные карты
*карта для доступа в помещение
*парковочная карта
*билеты в кино
*инициализация Bluetooth и других видов соединения

==NFC для бесконтактной оплаты==
Ведущие платёжные системы (Visa, MasterCard, American Express) позволяют осуществлять бесконтактные платежи на основе стандарта ISO/IEC 14443 в соответствии со спецификацией [[EMV]]. Эта технология называется PayPass в MasterCard, payWave в Visa и ExpressPay в American Express. Для бесконтактного платежа в этом случае требуется смарт-карта [[EMV]] с бесконтактым интерфейсом и терминал, принимающий такие карты.

Существуют способы эмуляции платежной [[EMV]] карты на смартфоне, оснащённом NFC интерфейсом. Есть два основных подхода.

Первый заключается в том, что смартфон после установки соответствующего приложения фактически становится полным аналогом обычной платёжной карты. В этом случае для осуществления транзакции задействуется элемент безопасности (Secure Element) — интегрированный в USIM, microSD или NFC чип, защищённый от взлома и кражи информации. Секретные ключи хранятся в Secure Element, что предотвращает риск их кражи. Существенным минусом виртуальных карт на базе Secure Element является необходимость строить сложную перекрестную систему доверия между производителями соответствующих чипов с интегрированными Secure Element (мобильные операторы или производители смартфонов) и банками-эмитентами. Для решения этой задачи предлагается задействовать дополнительных участников, являющихся доверенной стороной — Trusted Service Manager (TSM), что теоретически должно несколько упрощать столь сложную ситуацию. Однако на практике не всегда возможно договориться со всеми участниками.

Второй способ осуществления бесконтактных платежей при помощи мобильных устройств основывается на использовании технологии эмуляции карты только на основе программного обеспечения - Host Card Emulation ([[HCE]]). В этом случае на смартфоне не хранится PAN (Primary Account Number) или секретные ключи. Эти данные хранятся на стороне банка-эмитента, а смартфон лишь получает токены для платежа и использует их при бесконтактной оплате. При таком подходе нет зависимости от производителя телефона или от мобильного оператора, а также нет необходимости построения сложной схемы доверия, как при использовании Secure Element. В то же время данное решение соответствует стандартам [[EMV]] и сохраняет высокий уровень безопасности, благодаря тому, что никакая чувствительная информация не хранится на мобильном устройстве.

Использование HCE, позволяет перейти от мобильных платежей к [[Облачные вычисления|облачным]] платежам, благодаря опубликованной в начале 2014 года спецификации [[EMV]] о токенизации транзакций.

OATH

2016-08-09T12:51:28Z

Korabelnikov:

'''OATH''' (Open AuTHentication, [http://www.openauthentication.org]) — международная инициативная группа, состоящая из разработчиков систем строгой аутентификации, основной целью которой являются стандартизация (разработка стандартов на уровне RFC) алгоритмов генерации одноразовых паролей ([[одноразовый пароль|OTP, one-time password]]) и разработка архитектуры решения. Основная идея — обеспечить полную совместимость компонентов решения по [[строгая аутентификация|строгой аутентификации]] разных производителей. Для формализации этой задачи разработана Программа OATH-Сертификации (OATH Certification Program [http://www.openauthentication.org/certification]).

В инициативную группу OATH входят такие компании, как [http://powersecurity.ru/ru/solutions/nexussafe/ neXus(PortWise)], [http://powersecurity.ru/ru/solutions/nids/ Nagra ID], ActivIdentity, Entrust, Gemalto, Lieberman Software, N-Crypt, Symantec, SanDisk, TotalTexto, VeriSign и другие.

Основные наработки:

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по событию (event-base) — [[HOTP]], описан в виде RFC 4226

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по времени (time-base) — [[TOTP]], описан в виде RFC 6238

*Асинхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] в режиме запрос-ответ (challenge-response) — [[OCRA]], описан в виде RFC 6287

*Стандарт конфигурационного файла генератора [[одноразовый пароль|одноразовых паролей]] (переносимый контейнер симметричного колюч) — PSKC (Portable Symmetric Key Container), описан в виде RFC 6030

Кроме того было разработано описание архитектуры в виде документа OATH Reference Architecture (текущая версия — вторая) [http://www.openauthentication.org/webfm_send/1]

HSM

2016-08-09T12:31:25Z

Korabelnikov:

'''Hardware security module (HSM)''' — аппаратное вычислительное устройство, предназначенное для безопасного осуществления криптографических операций. HSM содержит специальный криптопроцессор, предназначенный для высокоскоросного выполнения криптографических процедур. Крупнейшие производители HSM на мировом рынке: Thales, SafeNet, Utimaco.

==Преимущества использования==
* генерация криптографических ключей;
* защищённое хранение секретных ключей;
* высокая скорость криптографических операций таких как шифрование, вычисление хэша, создание и проверка электронной подписи (ЭП);

==Особенности==
Существуют различные форм-факторы модулей HSM: от PCIx карты до выполненного в 19-дюймовом корпусе устройства, предназначенного для установки в серверном шкафу.
Существуют HSM, подключаемые по сети. В таком случае, они могут быть доступны нескольким серверам одновременно.

==Виртуализация HSM==
Подход "криптография как сервис" был воплощен в решениях виртуализации HSM. Примером таких решений является [http://powersecurity.ru/ru/solutions/power-security-hsm-factory/ Power Security HSM Factory]. Будучи надстройкой над кластером HSM виртуальные HSM могут быть использованы разными сервисами, как будто они работают с выделенным HSM. Помимо сокращения расходов на содержание парка HSM, этот подход позволяет реальзовать централизованое управление аппаратными модулями безопасности и быстрые запуск или изменения в решениях, использующих его.

==Применение==
Наибольшее распространение HSM получили в системах требующих повышенной безопасности и высокой скорости работы, как инфраструктура открытых ключей ([[PKI]]) или системы дистанционного банковского обслуживания. Генерация и хранение закрытого ключа Удостоверяющего Центра (в инфраструктуре [[PKI]]) позволяет гарантировать секретность этого ключа, так как он никогда не покидает защищённую область памяти HSM.
При работе с базой данных критически важная информация, например, пароли, хранятся в зашифрованном виде. Шифрование этих данных ключом, хранящемся на HSM, позволяет избежать оперирования ими в открытом виде вне HSM. Также одной из задач модуля HSM является «ускорение» SSL/TLS за счёт генерации на нем сессионного ключа.

Токен

2016-08-09T12:23:21Z

Korabelnikov:

[[image:tok.png|border|300px|thumb|right]]
'''Токен''' (от англ. '''Token''') – физическое устройство, содержащее чип [[смарт-карта| смарт-карты]] и, как правило, подключаемое к USB-порту. Токен комбинирует в себе преимущества [[смарт-карта| смарт-карты]] с удобным интерфейсом подключения без необходимости использования специального считывателя. Как правило, токены выполнены в виде брелка и удобны в использовании.

==Назначение токенов==
Токены позволяют решать широкий спектр задач и предназначены для:
*Авторизации пользователя в системе, приложении и др.;
*Проставления электронной подписи (ЭЦП);
*Организации безопасного удаленного доступа к информационным ресурсам;
*Надежного хранения персональных данных;
*Др.

PKI

2016-08-09T12:20:52Z

Korabelnikov: /* Источники */

[[image:PKI.png|border|300px|thumb|right]]
Криптография на основе открытых ключей, пожалуй, является одним из наиболее практичных инновационных решений в области математики 20 века, которое оказало огромное влияние на технологии компьютерной безопасности. Инфраструктура открытых ключей (ИОК, PKI, Public Key Infrastructure) – гибкая и масштабируемая инфраструктура для организации безопасной идентификации, аутентификации, обеспечения конфиденциальности и целостности данных в процессе взаимодействия (обмена данными) или получения каких-либо услуг. В эпоху глобальных коммуникаций и стремительного развития всемирной сети Интернет и мобильных сервисов, PKI предложило общие механизмы безопасности для применения в различных типах приложений и является неизбежным с точки зрения реализации в определенных сферах применения. Инфраструктура открытых ключей обеспечивает пользователей электронными идентификаторами (цифровыми сертификатами), включая управление и подтверждение состояния актуальности на протяжении всего жизненного цикла. Электронные идентификаторы могут рассматриваться в качестве неких «пользовательских паспортов», с помощью которых пользователи смогут получить доступ к определенным ресурсам, вести важную переписку в корпоративной или публичной сети или проводить дорогостоящие электронные транзакции.

==Основная концепция==
'''Инфраструктура открытых ключей (ИОК)''' – это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных системах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах жизненного цикла, обеспечивая взаимодействие всех средств защиты распределенной системы.

Инфраструктура открытых ключей является самой гибкой, масштабируемой и безопасной технологией, которая обеспечивает пользователей информации и информационных систем (люди и устройства) цифровыми идентификаторами (сертификатами). Пользователи могут использовать цифровые сертификаты для решения различных задач: аутентификация, цифровая подпись и шифрование. В PKI у каждого пользователя есть ключевая пара и сертификат. Ключ является последовательностью цифровых данных и используется для осуществления криптографических операций таких, как подписание и шифрование. Ключевая пара состоит из открытого и закрытого ключей, где закрытый ключ является неким «секретом» и хранится только в устройстве пользователя (смарт-карте, ПК, телефоне или др.). Благодаря тому, что закрытый ключ невозможно вычислить из соответствующего ему открытого ключа, последний публично известен. Сертификат хранит в себе пользовательские данные, какую-либо проверочную информацию и сам открытый ключ и располагается в идентификационной карте пользователя. Удостоверяющий центр (УЦ) осуществляет подписание и публикацию сертификата. Подпись УЦ доказывает наличие у пользователя пары ключей.

==Основные функции PKI==
*Аутентификация пользователей;
*Проверка валидности сертификатов;
*Обеспечение целостности данных;
*Неотказуемость;
*Конфиденциальность.

==Ключевые принципы PKI==
*Только владелец знает о своем закрытом ключе;
*УЦ генерирует сертификат открытого ключа, что позволяет удостоверить данный ключ;
*Доверие выстраивается только между владельцами сертификатов (пользователями) и УЦ, но друг с другом;
*Проверка (подтверждение/отказ) принадлежности открытого ключа заданному пользователю осуществляется УЦ.

==Участники инфраструктуры PKI==

'''Центр Регистрации''' (Регистрационный Центр) – компонент системы, являющийся не обязательной ее частью, который предназначен для регистрации пользователей.

'''Центр Сертификации''' (Удостоверяющий Центр) – организация или ее подразделение, выдающая сертификаты открытого ключа электронной цифровой подписи и управляющая криптографическими ключами пользователей.

'''Узел''' – наименьшая структурная единица в сети. Узел представляет собой компьютер конечного пользователя.

'''Сертификат ключа подписи''' - документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику информационной системы для подтверждения подлинности электронной цифровой подписи и идентификации владельца сертификата ключа подписи.

'''Хранилище сертификатов''' (Репозиторий) – хранилище цифровых сертификатов и списков отозванных сертификатов, служащее также средством распространения между пользователями системы.

'''Архив сертификатов''' – хранилище цифровых сертификатов, в котором располагаются все когда-либо изданные сертификаты с целью проверки ранее подписанных ЭЦП документов.

'''Центр запросов''' – компонент системы, с помощью которого пользователи системы смогут отправить запрос или отозвать действующий сертификат.

==Цифровой сертификат==
включает в себя:
*Идентификационные данные о владельце сертификатa;
*Уникальный открытый ключ владельца сертификата;
*Срок действия сертификата;
*Цифровую подпись УЦ.

==Ключевые решения на рынке==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-pki/ OpenTrust PKI];
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-certificate-manager/ neXus Certificate Manager];
*[http://www.cryptopro.ru/products/ca КриптоПро УЦ];
*Microsoft CA;
*Rsa Keon.

==Источники==
#Запечников С. В. Криптографические протоколы и их применение в финансовой и коммерческой деятельности. Горячая линия – Телеком, 2007. – 320 с.
#Полянская О. Ю., Горбатов В. С. Инфраструктура открытых ключей. Учебное пособие., Москва, 2007.
#[http://www.nexusgroup.com/Documents/SolutionBriefs_eng/neXus-PKI-Solution-Brief.pdf neXus PKI Solution Brief]. Краткое техническое описание компании NeXus.
#[http://base.garant.ru/184059/1/#block_100 ФЗ №1 «Об электронной цифровой подписи.»]

PKI

2016-08-09T12:20:22Z

Korabelnikov: /* Ключевые решения на рынке */

[[image:PKI.png|border|300px|thumb|right]]
Криптография на основе открытых ключей, пожалуй, является одним из наиболее практичных инновационных решений в области математики 20 века, которое оказало огромное влияние на технологии компьютерной безопасности. Инфраструктура открытых ключей (ИОК, PKI, Public Key Infrastructure) – гибкая и масштабируемая инфраструктура для организации безопасной идентификации, аутентификации, обеспечения конфиденциальности и целостности данных в процессе взаимодействия (обмена данными) или получения каких-либо услуг. В эпоху глобальных коммуникаций и стремительного развития всемирной сети Интернет и мобильных сервисов, PKI предложило общие механизмы безопасности для применения в различных типах приложений и является неизбежным с точки зрения реализации в определенных сферах применения. Инфраструктура открытых ключей обеспечивает пользователей электронными идентификаторами (цифровыми сертификатами), включая управление и подтверждение состояния актуальности на протяжении всего жизненного цикла. Электронные идентификаторы могут рассматриваться в качестве неких «пользовательских паспортов», с помощью которых пользователи смогут получить доступ к определенным ресурсам, вести важную переписку в корпоративной или публичной сети или проводить дорогостоящие электронные транзакции.

==Основная концепция==
'''Инфраструктура открытых ключей (ИОК)''' – это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных системах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах жизненного цикла, обеспечивая взаимодействие всех средств защиты распределенной системы.

Инфраструктура открытых ключей является самой гибкой, масштабируемой и безопасной технологией, которая обеспечивает пользователей информации и информационных систем (люди и устройства) цифровыми идентификаторами (сертификатами). Пользователи могут использовать цифровые сертификаты для решения различных задач: аутентификация, цифровая подпись и шифрование. В PKI у каждого пользователя есть ключевая пара и сертификат. Ключ является последовательностью цифровых данных и используется для осуществления криптографических операций таких, как подписание и шифрование. Ключевая пара состоит из открытого и закрытого ключей, где закрытый ключ является неким «секретом» и хранится только в устройстве пользователя (смарт-карте, ПК, телефоне или др.). Благодаря тому, что закрытый ключ невозможно вычислить из соответствующего ему открытого ключа, последний публично известен. Сертификат хранит в себе пользовательские данные, какую-либо проверочную информацию и сам открытый ключ и располагается в идентификационной карте пользователя. Удостоверяющий центр (УЦ) осуществляет подписание и публикацию сертификата. Подпись УЦ доказывает наличие у пользователя пары ключей.

==Основные функции PKI==
*Аутентификация пользователей;
*Проверка валидности сертификатов;
*Обеспечение целостности данных;
*Неотказуемость;
*Конфиденциальность.

==Ключевые принципы PKI==
*Только владелец знает о своем закрытом ключе;
*УЦ генерирует сертификат открытого ключа, что позволяет удостоверить данный ключ;
*Доверие выстраивается только между владельцами сертификатов (пользователями) и УЦ, но друг с другом;
*Проверка (подтверждение/отказ) принадлежности открытого ключа заданному пользователю осуществляется УЦ.

==Участники инфраструктуры PKI==

'''Центр Регистрации''' (Регистрационный Центр) – компонент системы, являющийся не обязательной ее частью, который предназначен для регистрации пользователей.

'''Центр Сертификации''' (Удостоверяющий Центр) – организация или ее подразделение, выдающая сертификаты открытого ключа электронной цифровой подписи и управляющая криптографическими ключами пользователей.

'''Узел''' – наименьшая структурная единица в сети. Узел представляет собой компьютер конечного пользователя.

'''Сертификат ключа подписи''' - документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику информационной системы для подтверждения подлинности электронной цифровой подписи и идентификации владельца сертификата ключа подписи.

'''Хранилище сертификатов''' (Репозиторий) – хранилище цифровых сертификатов и списков отозванных сертификатов, служащее также средством распространения между пользователями системы.

'''Архив сертификатов''' – хранилище цифровых сертификатов, в котором располагаются все когда-либо изданные сертификаты с целью проверки ранее подписанных ЭЦП документов.

'''Центр запросов''' – компонент системы, с помощью которого пользователи системы смогут отправить запрос или отозвать действующий сертификат.

==Цифровой сертификат==
включает в себя:
*Идентификационные данные о владельце сертификатa;
*Уникальный открытый ключ владельца сертификата;
*Срок действия сертификата;
*Цифровую подпись УЦ.

==Ключевые решения на рынке==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-pki/ OpenTrust PKI];
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-certificate-manager/ neXus Certificate Manager];
*[http://www.cryptopro.ru/products/ca КриптоПро УЦ];
*Microsoft CA;
*Rsa Keon.

==Источники==
#Запечников С. В. Криптографические протоколы и их применение в финансовой и коммерческой деятельности. Горячая линия – Телеком, 2007. – 320 с.
#Полянская О. Ю., Горбатов В. С. Инфраструктура открытых ключей. Учебное пособие., Москва, 2007.
#[http://www.nexusgroup.com/Documents/SolutionBriefs_eng/neXus-PKI-Solution-Brief.pdf NeXus PKI Solution Brief]. Краткое техническое описание компании NeXus.
#[http://base.garant.ru/184059/1/#block_100 ФЗ №1 «Об электронной цифровой подписи.»]

OpenTrust

2016-08-09T12:17:22Z

Korabelnikov: /* Российский рынок */

OpenTrust ([http://www.keynectis.com/en Keynectis])

==История==

Французская компания, начавшая свою работу как системный интегратор, специализирующийся на внедрении решений в области [http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%8B%D1%85_%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%B9 инфраструктуры открытых ключей (PKI)] на базе open-source продуктов.
В процессе реализации таких проектов каждый раз выполнялась серьёзная доработка используемого решения под требования заказчика, что привело к накоплению достаточно большого перечня, скажем так, дополнительного функционала, надстраиваемого над бесплатным и открытым PKI-движком.
Накопленный опыт, оттачиваемый от проекта к проекту и постоянно расширяемый функционал сподвиг копанию-интегратор к вполне видимому шагу: стать вендором коммерческого PKI-решения и переместиться из системной интеграции в область разработки, оставив при этом в своем портфеле услуги по внедрению своих же продуктов ([http://powersecurity.ru/ru/needs/ professional services]).

До недавнего времени учредителями компании OpenTrust были частные инвесторы, [http://www.Gemalto.com Gemalto] и государственные компании Франции. Не так давно компания OpenTrust была приобретена государственной компанией Франции [http://www.keynectis.com/en Keynectis], специализирующейся в разработке, поставке и внедрении специфических PKI-систем для государственных структур, в первую очередь Франции (в частности [http://www.keynectis.com/en Keynectis] специализируется в области комплексных решений для инфраструктуры электронных паспортов).

Существует мнение, что в ближайшее время OpenTrust полностью ассимилирует в эко-системе [http://www.keynectis.com/en Keynectis], включая полный ребрендинг разрабатываемых продуктов.

==Продукты и решения OpenTrust (Keynectis)==
Ожидаемым шагом, после запуска коммерческой версии PKI ([http://powersecurity.ru/ru/products/pki/opentrust-pki/ OpenTrust PKI]) стала разработка коммерческой версии системы управления жизненным циклом смарт-карт [http://powersecurity.ru/ru/products/cms/opentrust-cms/ OpenTrust CMS], которая поддерживает все востребованные модели [http://powersecurity.ru/ru/support/wiki/index.php?title=%D0%A1%D0%BC%D0%B0%D1%80%D1%82-%D0%BA%D0%B0%D1%80%D1%82%D0%B0 смарт-карт] и [http://powersecurity.ru/ru/support/wiki/index.php?title=%D0%A2%D0%BE%D0%BA%D0%B5%D0%BD usb-токенов] на нативном уровне (что есть очень хорошо).
Третьим продуктом стала система защищенного (управляемого) файлобмена — [http://powersecurity.ru/ru/products/mft/opentrust-mft/ OpenTrust MFT] (Managed File Transfer).

Вполне понятно (к этому обязывают истоки компании и это хорошо), что все продукты компании OpenTrust работают под управлением [http://www.linux.org/ Linux].

==Заслуги и прочие медальки==
Очевидной заслугой, которую можно приписать OpenTrust (что бы там не говорили всякие и разные) — это авторство концепции Next-Generation PKI, которая влила новые свежую кровь в эту технологию, скажем так, с бородой.

==Российский рынок==
На российском рынке компания [http://powersecurity.ru/ru/about/partners/opentrust/ OpenTrust] делает уверенные шаги, которые заключаются в первую очередь в адаптации продуктов к Российским реалиям.

===Российская криптография===
По понятным причинам PKI-решение необходимо ГОСТифицировать. Что и было успешно реализовано. Так как в основе движка лежит OpenSSL, задача решалась именно в этом направлении: была проведена совместная работа с компанией [http://cryptocom.ru/ КриптоКом] (активным участником [http://cryptocom.ru/opensource/ open source] проекта [http://cryptocom.ru/opensource/openssl100.html openSSL], разработчиком [http://cryptocom.ru/solutions/index.html сертифицированных СКЗИ]) по интеграции сертифицированного криптомодуля реализующего ГОСТовые алгоритмы в [http://openssl.org/ openSSL].

===Российские смарт-карты===
Так как таковых нет, а есть Российские usb-токены, то была проведена реализована поддержка управления их жизненным циклом в соответствующей системе — [http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS]. Речь, понятно, идет о [http://www.rutoken.ru/ ruToken (руТокен)] производства Актив (Актив-Софт). Другой, очень популярный в России производитель как смарт-карт, так и usb-токенов [http://Aladdin-rd.ru Aladdin] ныне [http://safenet-inc.com SafeNet] с решениями [http://www.aladdin-rd.ru/catalog/etoken/ eToken] поддерживается давно и очень активно, но не благодаря попыткам закрепиться на российском рынке, а из-за мировой популярности этого решения, которое у нас стало практически именем нарицательным

===Российская криптография (2)===
Она же, как и в PKI тем же самым путем была реализована в MFT (что хорошо)

===Сертификация===
Делаются определенные потуги по сертификации некоторых продуктов в некоторых органах, [http://fsb.ru/ authority], так сказать. Пожелаем им успехов!

OpenTrust

2016-08-09T12:16:17Z

Korabelnikov: /* Продукты и решения OpenTrust (Keynectis) */

OpenTrust ([http://www.keynectis.com/en Keynectis])

==История==

Французская компания, начавшая свою работу как системный интегратор, специализирующийся на внедрении решений в области [http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%8B%D1%85_%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%B9 инфраструктуры открытых ключей (PKI)] на базе open-source продуктов.
В процессе реализации таких проектов каждый раз выполнялась серьёзная доработка используемого решения под требования заказчика, что привело к накоплению достаточно большого перечня, скажем так, дополнительного функционала, надстраиваемого над бесплатным и открытым PKI-движком.
Накопленный опыт, оттачиваемый от проекта к проекту и постоянно расширяемый функционал сподвиг копанию-интегратор к вполне видимому шагу: стать вендором коммерческого PKI-решения и переместиться из системной интеграции в область разработки, оставив при этом в своем портфеле услуги по внедрению своих же продуктов ([http://powersecurity.ru/ru/needs/ professional services]).

До недавнего времени учредителями компании OpenTrust были частные инвесторы, [http://www.Gemalto.com Gemalto] и государственные компании Франции. Не так давно компания OpenTrust была приобретена государственной компанией Франции [http://www.keynectis.com/en Keynectis], специализирующейся в разработке, поставке и внедрении специфических PKI-систем для государственных структур, в первую очередь Франции (в частности [http://www.keynectis.com/en Keynectis] специализируется в области комплексных решений для инфраструктуры электронных паспортов).

Существует мнение, что в ближайшее время OpenTrust полностью ассимилирует в эко-системе [http://www.keynectis.com/en Keynectis], включая полный ребрендинг разрабатываемых продуктов.

==Продукты и решения OpenTrust (Keynectis)==
Ожидаемым шагом, после запуска коммерческой версии PKI ([http://powersecurity.ru/ru/products/pki/opentrust-pki/ OpenTrust PKI]) стала разработка коммерческой версии системы управления жизненным циклом смарт-карт [http://powersecurity.ru/ru/products/cms/opentrust-cms/ OpenTrust CMS], которая поддерживает все востребованные модели [http://powersecurity.ru/ru/support/wiki/index.php?title=%D0%A1%D0%BC%D0%B0%D1%80%D1%82-%D0%BA%D0%B0%D1%80%D1%82%D0%B0 смарт-карт] и [http://powersecurity.ru/ru/support/wiki/index.php?title=%D0%A2%D0%BE%D0%BA%D0%B5%D0%BD usb-токенов] на нативном уровне (что есть очень хорошо).
Третьим продуктом стала система защищенного (управляемого) файлобмена — [http://powersecurity.ru/ru/products/mft/opentrust-mft/ OpenTrust MFT] (Managed File Transfer).

Вполне понятно (к этому обязывают истоки компании и это хорошо), что все продукты компании OpenTrust работают под управлением [http://www.linux.org/ Linux].

==Заслуги и прочие медальки==
Очевидной заслугой, которую можно приписать OpenTrust (что бы там не говорили всякие и разные) — это авторство концепции Next-Generation PKI, которая влила новые свежую кровь в эту технологию, скажем так, с бородой.

==Российский рынок==
На российском рынке компания OpenTrust делает уверенные шаги, которые заключаются в первую очередь в адаптации продуктов к Российским реалиям.

===Российская криптография===
По понятным причинам PKI-решение необходимо ГОСТифицировать. Что и было успешно реализовано. Так как в основе движка лежит OpenSSL, задача решалась именно в этом направлении: была проведена совместная работа с компанией [http://cryptocom.ru/ КриптоКом] (активным участником [http://cryptocom.ru/opensource/ open source] проекта [http://cryptocom.ru/opensource/openssl100.html openSSL], разработчиком [http://cryptocom.ru/solutions/index.html сертифицированных СКЗИ]) по интеграции сертифицированного криптомодуля реализующего ГОСТовые алгоритмы в [http://openssl.org/ openSSL].

===Российские смарт-карты===
Так как таковых нет, а есть Российские usb-токены, то была проведена реализована поддержка управления их жизненным циклом в соответствующей системе — [http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS]. Речь, понятно, идет о [http://www.rutoken.ru/ ruToken (руТокен)] производства Актив (Актив-Софт). Другой, очень популярный в России производитель как смарт-карт, так и usb-токенов [http://Aladdin-rd.ru Aladdin] ныне [http://safenet-inc.com SafeNet] с решениями [http://www.aladdin-rd.ru/catalog/etoken/ eToken] поддерживается давно и очень активно, но не благодаря попыткам закрепиться на российском рынке, а из-за мировой популярности этого решения, которое у нас стало практически именем нарицательным

===Российская криптография (2)===
Она же, как и в PKI тем же самым путем была реализована в MFT (что хорошо)

===Сертификация===
Делаются определенные потуги по сертификации некоторых продуктов в некоторых органах, [http://fsb.ru/ authority], так сказать. Пожелаем им успехов!

CMS

2016-08-09T12:09:09Z

Korabelnikov: /* Существующие решения */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*[[HSM]];
*Пользовательские директории;
*Принтер для [[Смарт-карта|смарт-карт]];
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/products/cms/nexus-smartact/ neXus SmartACT],[http://powersecurity.ru/ru/products/cms/nexus-proact/ neXus ProACT] и [http://powersecurity.ru/ru/products/cms/nexus-prime/ neXus PRIME] от [http://powersecurity.ru/ru/solutions/nexussafe/ Technology neXus]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

CMS

2016-08-09T12:08:11Z

Korabelnikov: /* Существующие решения */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*[[HSM]];
*Пользовательские директории;
*Принтер для [[Смарт-карта|смарт-карт]];
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/products/cms/nexus-smartact/ neXus SmartACT],[http://powersecurity.ru/ru/products/cms/nexus-proact/ neXus ProACT] и [http://powersecurity.ru/ru/products/cms/nexus-prime/ neXus PRIME] от [http://powersecurity.ru/ru/solutions/nexussafe/ neXus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

CMS

2016-08-09T12:06:46Z

Korabelnikov: /* Существующие решения */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*[[HSM]];
*Пользовательские директории;
*Принтер для [[Смарт-карта|смарт-карт]];
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-smartact/ neXus SmartACT],[http://powersecurity.ru/ru/products/cms/nexus-proact/ neXus ProACT] и [http://powersecurity.ru/ru/solutions/nexussafe/nexus-prime/ neXus PRIME] от [http://powersecurity.ru/ru/solutions/nexussafe/ neXus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

CMS

2016-08-09T12:05:37Z

Korabelnikov: /* Существующие решения */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*[[HSM]];
*Пользовательские директории;
*Принтер для [[Смарт-карта|смарт-карт]];
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-smartact/ Nexus SmartACT],[http://powersecurity.ru/ru/products/cms/nexus-proact/ Nexus ProACT] и [http://powersecurity.ru/ru/solutions/nexussafe/nexus-prime/ Nexus PRIME] от [http://powersecurity.ru/ru/solutions/nexussafe/ Nexus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

NFC

2014-05-22T06:59:02Z

Korabelnikov: /* NFC для бесконтактной оплаты */

'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций небольшого радиуса действия (на расстоянии нескольких сантиметров). NFC является расширением стандарта ISO/IEC 14443 (стандарт бесконтактных карт) и работает на частоте 13,56 MHz в соответствии с ISO/IEC 18000-3; позволяет передавать данные со скоростью от 106 до 424 кбит/с.

==Описание==
Требуется две стороны для передачи данных: инициатор и целевое устройство. Инициатор создаёт электромагнитное поле, благодаря которому целевое устройство получает питание.

NFC позволяет осуществлять не только одностороннюю связь, когда инициатор получает данные с целевого устройства (пассивный режим), но и двухстороннее общение (активный режим), для чего оба устройства должны обладать источником энергии.

==Стандартизация==
Обеспечением совместимости и разработкой спецификаций занимается ассоциация '''GSM Association''' ('''GSMA'''), состоящая из примерно 800 операторов мобильной связи и 200 других компаний.

Продвижением использования NFC в мобильных устройствах и бытовой электронике занимается организация '''NFC Forum'''.

'''[[EMV]]Co''' разрабатывает спецификации для осуществления бесконтактных платежей.

'''GlobalPlatform''' — некоммерческая ассоциация, разрабатывающая архитектуру элемента безопасности (Secure Element).

==Применения NFC в мобильных устройствах==
Технология NFC находит большое количество применений в разных сферах, например:
*передача данных
*банковские платёжные карты
*транспортные карты
*карта для доступа в помещение
*парковочная карта
*билеты в кино
*инициализация Bluetooth и других видов соединения

==NFC для бесконтактной оплаты==
Ведущие платёжные системы (Visa, MasterCard, American Express) позволяют осуществлять бесконтактные платежи на основе стандарта ISO/IEC 14443 в соответствии со спецификацией [[EMV]]. Эта технология называется PayPass в MasterCard, payWave в Visa и ExpressPay в American Express. Для бесконтактного платежа в этом случае требуется смарт-карта [[EMV]] с бесконтактым интерфейсом и терминал, принимающий такие карты.

Существуют способы эмуляции платежной [[EMV]] карты на смартфоне, оснащённом NFC интерфейсом. Есть два основных подхода.

Первый заключается в том, что смартфон после установки соответствующего приложения фактически становится полным аналогом обычной платёжной карты. В этом случае для осуществления транзакции задействуется элемент безопасности (Secure Element) — интегрированный в USIM, microSD или NFC чип, защищённый от взлома и кражи информации. Секретные ключи хранятся в Secure Element, что предотвращает риск их кражи. Существенным минусом виртуальных карт на базе Secure Element является необходимость строить сложную перекрестную систему доверия между производителями соответствующих чипов с интегрированными Secure Element (мобильные операторы или производители смартфонов) и банками-эмитентами. Для решения этой задачи предлагается задействовать дополнительных участников, являющихся доверенной стороной — Trusted Service Manager (TSM), что теоретически должно несколько упрощать столь сложную ситуацию. Однако на практике не всегда возможно договориться со всеми участниками.

Второй способ осуществления бесконтактных платежей при помощи мобильных устройств основывается на использовании технологии эмуляции карты только на основе программного обеспечения - Host Card Emulation (HCE). В этом случае на смартфоне не хранится PAN (Primary Account Number) или секретные ключи. Эти данные хранятся на стороне банка-эмитента, а смартфон лишь получает токены для платежа и использует их при бесконтактной оплате. При таком подходе нет зависимости от производителя телефона или от мобильного оператора, а также нет необходимости построения сложной схемы доверия, как при использовании Secure Element. В то же время данное решение соответствует стандартам [[EMV]] и сохраняет высокий уровень безопасности, благодаря тому, что никакая чувствительная информация не хранится на мобильном устройстве.

Использование HCE, позволяет перейти от мобильных платежей к [[Облачные вычисления|облачным]] платежам, благодаря опубликованной в начале 2014 года спецификации [[EMV]] о токенизации транзакций.

NFC

2014-05-22T06:51:40Z

Korabelnikov: /* NFC для бесконтактной оплаты */

'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций небольшого радиуса действия (на расстоянии нескольких сантиметров). NFC является расширением стандарта ISO/IEC 14443 (стандарт бесконтактных карт) и работает на частоте 13,56 MHz в соответствии с ISO/IEC 18000-3; позволяет передавать данные со скоростью от 106 до 424 кбит/с.

==Описание==
Требуется две стороны для передачи данных: инициатор и целевое устройство. Инициатор создаёт электромагнитное поле, благодаря которому целевое устройство получает питание.

NFC позволяет осуществлять не только одностороннюю связь, когда инициатор получает данные с целевого устройства (пассивный режим), но и двухстороннее общение (активный режим), для чего оба устройства должны обладать источником энергии.

==Стандартизация==
Обеспечением совместимости и разработкой спецификаций занимается ассоциация '''GSM Association''' ('''GSMA'''), состоящая из примерно 800 операторов мобильной связи и 200 других компаний.

Продвижением использования NFC в мобильных устройствах и бытовой электронике занимается организация '''NFC Forum'''.

'''[[EMV]]Co''' разрабатывает спецификации для осуществления бесконтактных платежей.

'''GlobalPlatform''' — некоммерческая ассоциация, разрабатывающая архитектуру элемента безопасности (Secure Element).

==Применения NFC в мобильных устройствах==
Технология NFC находит большое количество применений в разных сферах, например:
*передача данных
*банковские платёжные карты
*транспортные карты
*карта для доступа в помещение
*парковочная карта
*билеты в кино
*инициализация Bluetooth и других видов соединения

==NFC для бесконтактной оплаты==
Ведущие платёжные системы (Visa, MasterCard, American Express) позволяют осуществлять бесконтактные платежи на основе стандарта ISO/IEC 14443 в соответствии со спецификацией [[EMV]]. Эта технология называется PayPass в MasterCard, payWave в Visa и ExpressPay в American Express. Для бесконтактного платежа в этом случае требуется смарт-карта [[EMV]] с бесконтактым интерфейсом и терминал, принимающий такие карты.

Существуют способы эмуляции платежной [[EMV]] карты на смартфоне, оснащённом NFC интерфейсом. Есть два основных подхода.

Первый заключается в том, что смартфон после установки соответствующего приложения фактически становится полным аналогом обычной платёжной карты. В этом случае для осуществления транзакции задействуется элемент безопасности (Secure Element) — интегрированный в USIM, microSD или NFC чип, защищённый от взлома и кражи информации. Секретные ключи хранятся в Secure Element, что предотвращает риск их кражи. Существенным минусом виртуальных карт на базе Secure Element является необходимость строить сложную перекрестную систему доверия между производителями соответствующих чипов с интегрированными Secure Element (мобильные операторы или производители смартфонов) и банками-эмитентами. Для решения этой задачи предлагается задействовать дополнительных участников, являющихся доверенной стороной — Trusted Service Manager (TSM), что теоретически должно несколько упрощать столь сложную ситуацию. Однако на практике не всегда возможно договориться со всеми участниками.

Второй способ осуществления бесконтактных платежей при помощи мобильных устройств основывается на использовании технологии эмуляции карты только на основе программного обеспечения - Host Card Emulation (HCE). В этом случае на смартфоне не хранится PAN (Primary Account Number) или секретные ключи. Эти данные хранятся на стороне банка-эмитента, а смартфон лишь получает токены для платежа и использует их при бесконтактной оплате. При таком подходе нет зависимости от производителя телефона или от мобильного оператора, а также нет необходимости построения сложной схемы доверия, как при использовании Secure Element. В то же время данное решение соответствует стандартам [[EMV]] и сохраняет высокий уровень безопасности, благодаря тому, что никакая чувствительная информация не хранится на мобильном устройстве. Использование HCE, фактически, позволяет перейти от мобильных платежей к [[Облачные вычисления|облачным]] платежам.

NFC

2014-05-20T13:46:28Z

Korabelnikov:

'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций небольшого радиуса действия (на расстоянии нескольких сантиметров). NFC является расширением стандарта ISO/IEC 14443 (стандарт бесконтактных карт) и работает на частоте 13,56 MHz в соответствии с ISO/IEC 18000-3; позволяет передавать данные со скоростью от 106 до 424 кбит/с.

==Описание==
Требуется две стороны для передачи данных: инициатор и целевое устройство. Инициатор создаёт электромагнитное поле, благодаря которому целевое устройство получает питание.

NFC позволяет осуществлять не только одностороннюю связь, когда инициатор получает данные с целевого устройства (пассивный режим), но и двухстороннее общение (активный режим), для чего оба устройства должны обладать источником энергии.

==Стандартизация==
Обеспечением совместимости и разработкой спецификаций занимается ассоциация '''GSM Association''' ('''GSMA'''), состоящая из примерно 800 операторов мобильной связи и 200 других компаний.

Продвижением использования NFC в мобильных устройствах и бытовой электронике занимается организация '''NFC Forum'''.

'''[[EMV]]Co''' разрабатывает спецификации для осуществления бесконтактных платежей.

'''GlobalPlatform''' — некоммерческая ассоциация, разрабатывающая архитектуру элемента безопасности (Secure Element).

==Применения NFC в мобильных устройствах==
Технология NFC находит большое количество применений в разных сферах, например:
*передача данных
*банковские платёжные карты
*транспортные карты
*карта для доступа в помещение
*парковочная карта
*билеты в кино
*инициализация Bluetooth и других видов соединения

==NFC для бесконтактной оплаты==
Ведущие платёжные системы (Visa, MasterCard, American Express) позволяют осуществлять бесконтактные платежи на основе стандарта ISO/IEC 14443 в соответствии со спецификацией [[EMV]]. Эта технология называется PayPass в MasterCard, payWave в Visa и ExpressPay в American Express. Для бесконтактного платежа в этом случае требуется смарт-карта [[EMV]] с бесконтактым интерфейсом и терминал, принимающий такие карты.

Существуют способы эмуляции платежной [[EMV]] карты на смартфоне, оснащённом NFC интерфейсом. Есть два основных подхода.

Первый заключается в том, что смартфон после установки соответствующего приложения фактически становится полным аналогом обычной платёжной карты. В этом случае для осуществления транзакции задействуется элемент безопасности (Secure Element) — интегрированный в USIM, microSD или NFC чип, защищённый от взлома и кражи информации. Секретные ключи хранятся в Secure Element, что предотвращает риск их кражи. Существенным минусом виртуальных карт на базе Secure Element является необходимость строить сложную перекрестную систему доверия между производителями соответствующих чипов с интегрированными Secure Element (мобильные операторы или производители смартфонов) и банками-эмитентами. Для решения этой задачи предлагается задействовать дополнительных участников, являющихся доверенной стороной — Trusted Service Manager (TSM), что теоретически должно несколько упрощать столь сложную ситуацию. Однако на практике не всегда возможно договориться со всеми участниками.

Второй способ осуществления бесконтактных платежей при помощи мобильных устройств основывается на использовании технологии эмуляции карты только на основе программного обеспечения - Host Card Emulation (HCE). В этом случае на смартфоне не хранится PAN (Primary Account Number) или секретные ключи. Эти данные хранятся на стороне банка-эмитента, а смартфон лишь получает токены для платежа и использует их при бесконтактной оплате. При таком подходе нет зависимости от производителя телефона или от мобильного оператора, а также нет необходимости построения сложной схемы доверия, как при использовании Secure Element. В то же время данное решение соответствует стандартам [[EMV]] и сохраняет высокий уровень безопасности, благодаря тому, что никакая чувствительная информация не хранится на мобильном устройстве. Использование HCE является, фактически, переходом от мобильных платежей к облачным платежам.

NFC

2014-05-20T13:45:43Z

Korabelnikov: Новая страница: «'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций…»

'''NFC''' ('''Near Field Communication''') представляет собой набор технологий бесконтактных коммуникаций небольшого радиуса действия (на расстоянии нескольких сантиметров). NFC является расширением стандарта ISO 14443 (стандарт бесконтактных карт) и работает на частоте 13,56 MHz в соответствии с ISO/IEC 18000-3; позволяет передавать данные со скоростью от 106 до 424 кбит/с.

==Описание==
Требуется две стороны для передачи данных: инициатор и целевое устройство. Инициатор создаёт электромагнитное поле, благодаря которому целевое устройство получает питание.

NFC позволяет осуществлять не только одностороннюю связь, когда инициатор получает данные с целевого устройства (пассивный режим), но и двухстороннее общение (активный режим), для чего оба устройства должны обладать источником энергии.

==Стандартизация==
Обеспечением совместимости и разработкой спецификаций занимается ассоциация '''GSM Association''' ('''GSMA'''), состоящая из примерно 800 операторов мобильной связи и 200 других компаний.

Продвижением использования NFC в мобильных устройствах и бытовой электронике занимается организация '''NFC Forum'''.

'''[[EMV]]Co''' разрабатывает спецификации для осуществления бесконтактных платежей.

'''GlobalPlatform''' — некоммерческая ассоциация, разрабатывающая архитектуру элемента безопасности (Secure Element).

==Применения NFC в мобильных устройствах==
Технология NFC находит большое количество применений в разных сферах, например:
*передача данных
*банковские платёжные карты
*транспортные карты
*карта для доступа в помещение
*парковочная карта
*билеты в кино
*инициализация Bluetooth и других видов соединения

==NFC для бесконтактной оплаты==
Ведущие платёжные системы (Visa, MasterCard, American Express) позволяют осуществлять бесконтактные платежи на основе стандарта ISO/IEC 14443 в соответствии со спецификацией [[EMV]]. Эта технология называется PayPass в MasterCard, payWave в Visa и ExpressPay в American Express. Для бесконтактного платежа в этом случае требуется смарт-карта [[EMV]] с бесконтактым интерфейсом и терминал, принимающий такие карты.

Существуют способы эмуляции платежной [[EMV]] карты на смартфоне, оснащённом NFC интерфейсом. Есть два основных подхода.

Первый заключается в том, что смартфон после установки соответствующего приложения фактически становится полным аналогом обычной платёжной карты. В этом случае для осуществления транзакции задействуется элемент безопасности (Secure Element) — интегрированный в USIM, microSD или NFC чип, защищённый от взлома и кражи информации. Секретные ключи хранятся в Secure Element, что предотвращает риск их кражи. Существенным минусом виртуальных карт на базе Secure Element является необходимость строить сложную перекрестную систему доверия между производителями соответствующих чипов с интегрированными Secure Element (мобильные операторы или производители смартфонов) и банками-эмитентами. Для решения этой задачи предлагается задействовать дополнительных участников, являющихся доверенной стороной — Trusted Service Manager (TSM), что теоретически должно несколько упрощать столь сложную ситуацию. Однако на практике не всегда возможно договориться со всеми участниками.

Второй способ осуществления бесконтактных платежей при помощи мобильных устройств основывается на использовании технологии эмуляции карты только на основе программного обеспечения - Host Card Emulation (HCE). В этом случае на смартфоне не хранится PAN (Primary Account Number) или секретные ключи. Эти данные хранятся на стороне банка-эмитента, а смартфон лишь получает токены для платежа и использует их при бесконтактной оплате. При таком подходе нет зависимости от производителя телефона или от мобильного оператора, а также нет необходимости построения сложной схемы доверия, как при использовании Secure Element. В то же время данное решение соответствует стандартам [[EMV]] и сохраняет высокий уровень безопасности, благодаря тому, что никакая чувствительная информация не хранится на мобильном устройстве. Использование HCE является, фактически, переходом от мобильных платежей к облачным платежам.

CMS

2014-05-16T14:07:38Z

Korabelnikov: /* Интеграция с другими системами */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*[[HSM]];
*Пользовательские директории;
*Принтер для [[Смарт-карта|смарт-карт]];
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-smartact/ Nexus SmartACT] от [http://powersecurity.ru/ru/solutions/nexussafe/ Nexus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

Сервер аутентификации

2014-05-16T13:45:56Z

Korabelnikov: /* Ключевые особенности */

'''Сервер аутентификации''' (англ. '''Authentication Server''') – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент».

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

==Ключевые особенности==
*Поддержка различных моделей и типов генераторов одноразовых паролей
*Интеграция с сервисами
*Поддержка различных каналов аутентификации, методов аутентификации
*Безопасный доступ к серверу аутентификации
*Поддержка [[HSM]]-модулей
*Поддержка протокола RADIUS

Использование [[строгая аутентификация |многофакторной аутентификации]] непременно снижает риски компрометации аутентификационных данных клиента. Применение [[одноразовый пароль |одноразовых паролей]] (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта [[OATH |OATH]] ([[TOTP |TOTP]], [[HOTP |HOTP]], [[OCRA |OCRA]]) или [[EMV |EMV]], сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

''Пример:'' банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; [[HSM]]). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные [[HSM]] ([http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect Thales nShield], [http://www.safenet-inc.com/products/data-protection/hardware-security-modules-hsms/ SafeNet], [http://hsm.utimaco.com/products/ Utimaco], функционирующих в режиме FIPS).

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

==Примеры==
#[http://powersecurity.ru/ru/products/auth/nexus-portwise/auth-server/ neXus Portwise Authentication Server]
#[http://www.hidglobal.com/identity-assurance# ActivID Security Solutions]
#[http://www.thales-esecurity.com/products-and-services/products-and-services/identity-management/authentication/safesign-authentication-server SafeSign Authentication Server]

HSM

2014-05-16T13:23:23Z

Korabelnikov: Новая страница: «'''Hardware security module (HSM)''' — аппаратное вычислительное устройство, предназначенное для безоп…»

'''Hardware security module (HSM)''' — аппаратное вычислительное устройство, предназначенное для безопасного осуществления криптографических операций. HSM содержит специальный криптопроцессор, предназначенный для высокоскоросного выполнения криптографических процедур. Крупнейшие производители HSM на мировом рынке: Thales, SafeNet, Utimaco.

==Преимущества использования==
* генерация криптографических ключей;
* защищённое хранение секретных ключей;
* высокая скорость криптографических операций таких как шифрование, вычисление хэша, создание и проверка электронной подписи (ЭП);

==Особенности==
Существуют различные форм-факторы модулей HSM: от PCIx карты до выполненного в 19-дюймовом корпусе устройства, предназначенного для установки в серверном шкафу.
Существуют HSM, подключаемые по сети. В таком случае, они могут быть доступны нескольким серверам одновременно.

==Применение==
Наибольшее распространение HSM получили в системах требующих повышенной безопасности и высокой скорости работы, как инфраструктура открытых ключей ([[PKI]]) или системы дистанционного банковского обслуживания. Генерация и хранение закрытого ключа Удостоверяющего Центра (в инфраструктуре [[PKI]]) позволяет гарантировать секретность этого ключа, так как он никогда не покидает защищённую область памяти HSM.
При работе с базой данных критически важная информация, например, пароли, хранятся в зашифрованном виде. Шифрование этих данных ключом, хранящемся на HSM, позволяет избежать оперирования ими в открытом виде вне HSM. Также одной из задач модуля HSM является «ускорение» SSL/TLS за счёт генерации на нем сессионного ключа.

EMV

2014-05-15T15:38:33Z

Korabelnikov:

'''EMV''' (от первых букв названия трех платежных систем: Europay, MasterCard и VISA) — международный стандарт, разработанный Europay, MasterCard и Visa, определяющий правила проведения операций по банковским картам с чипом. Основная задача стандарта — повышение уровня безопасности, в данном случае, проводимых операций.
Обычно [[PIN]] необходим для проверки подлинности пользователя при контактном способе осуществления платежа, поэтому такие транзакции часто называют «Chip and [[PIN]]». Однако спецификация EMV включает и другие способы верификации держателя карты. Помимо спецификации контактного использования, разработаны и другие спецификации: бесконтактное использование, персонализация карт, токенизация.
Для осуществления он-лайн платежей через интернет или мобильный банк компания MasterCard разработала стандарт CAP (Chip Authentication Program). Аналогичный стандарт с некоторым отличиями от компании Visa называется DPA (Dynamic Password Authentication).

==Чип EMV==
Чип EMV представляет собой по сути микрокомпьютер содержащий микропроцессор, оперативную память, память длительного хранения. Питание чипа и обмен данными со считывающим устройством осуществляется через металлическую контактную площадку. При осуществлении бесконтактных платежей чип передаёт данные по радио частотам не требуя физической передачи карты.

==Сравнение с магнитной полосой==
Магнитная полоса представляет собой просто носитель информации с данными. Чип EMV — это микрокомпьютер, позволяющий не только хранить данные, но и производить необходимые операции. С магнитной полосы возможно считать данные и изготовить клон карты, в то время как скопировать все данные с чипа невозможно. Секретный ключ хранится в защищённой области памяти чипа и используется для идентификации карты считывающим устройством. Таким образом, использование EMV чипа позволяет повысить уровень безопасности, как самих данных на карте, так и платёжных операций с использованием карт.

Out-of-band

2014-02-05T08:05:34Z

Korabelnikov:

В аутентификации термин '''out-of-band''' означает использование независимого (альтернативного) канала (связи). Идея заключается в том, что в процессе аутентификации используется дополнительный канал связи, по которому передаются данные аутентификации или параметры подписи транзакции.
Атаки нацелены на основной канал, который используется в процессе выполнения транзакции и аутентификации, а использование второго нескомпрометированного канала позволяет разделить полезные данные (транзакционные) и данные аутентификации.

Наиболее распространенным альтернативным каналом является канал сотовой связи, по которому высылается одноразовый пароль в виде SMS, передаются код подтверждения транзакции вместе с основными параметрами транзакций. В качестве примера можно привести онлайн сервисы, предоставляемые банками: клиенты банка осуществляют подключение к онлайн сервисам используя логин и [[одноразовый пароль]], который отправялется на их мобильный телефон в виде SMS-сообщения. Основной канал - широкополосный доступ в итнернет, благодаря которому в браузере пользователя отображается окно входа, второй независимый канал - мобильная сеть.

Как развитие этого направления на мобильный телефон может быть установлено специальное программное обеспечение, которое взаимодействует с [[Сервер аутентификации|сервером аутентификации]] и авторизации для получения кодов авторизации и данных проводимой транзакции. Такой вариант более надежен, так как подразумевает шифрование канала связи мобильным устройством и сервером, а также имеет дополнительный уровень защиты в виде [[PIN|PIN]]-кода или пароля

Смарт-карта

2014-02-05T07:56:58Z

Korabelnikov: /* Источники */

[[image:sm-t.png|border|300px|thumb|right]]
'''Смарт-карта''' (от англ. '''Smart-Card''') – это пластиковая карта со встроенной микросхемой.
Смарт-карта является последним инновационным решением семейства идентификационных карт формата ID-1. Их характерной особенностью являются интегральные схемы, встроенные в корпус карты с компонентами для передачи, хранения и обработки информации. Данные могут передаваться на контакты карты или с помощью электромагнитного поля без использования контактов.

==История появления==
Технология смарт-карт прошла длительный путь становления. Ее история начинается с 1970-х годов, когда осуществлялись первые попытки внедрения энергонезависимой памяти и логики работы в чип карты, и продолжается вплоть до сегодняшнего дня.

Первоначально такая идея содержалась в заявке на патент от Юргена Детлоффа (Jürgen Dethloff) и Гельмута Гротруппа (Helmut Grötrupp) еще в 1968 году. Вслед за ними последовала похожая заявка от японца Kunitaka Arimure. Хотя реальное развитие смарт-карты получили во Франции в 1974 году, когда Роланд Морено (Roland Moreno) зарегистрировал свой патент на смарт-карту.

Первые пластиковые карты появились в 1950-х годах для осуществления безналичной оплаты. С момента вступления на рынок MasterCard и VISA, пластиковые карты стали быстро распространяться по всему миру. Первое поколение карт защищалось от подделки благодаря технологии безопасной печати и панелью подписи. Таким образом, безопасность карт полностью возлагалась на добросовестность и опыт сотрудников принимающих организаций.

Большой рост мошенничества привел к необходимости усовершенствования технологий безопасности. Первым улучшением стало появление магнитной полосы на обратной стороне карты. Следующим шагом стало использование [[PIN]]-кода (сравнивался с номером в терминале) для идентификации пользователя. Уязвимость магнитной полосы позволяла осуществлять действия (чтение/запись) с хранимыми на ней данными, что привело к необходимости хранения [[PIN]]-кодов в безопасной среде в защищенном виде.

Прорыв развития технологии смарт-карт был осуществлен в 1984-85 годах, когда во французских и немецких компаниях проводились тестовые испытания с телефонными картами. Результаты показали высокую надежность и безопасность смарт-карт. Хороший полученный опыт в аналоговых мобильных телефонных сетях оказал решающее значение для введения смарт-карт в цифровую сеть GSM.

Стоит отметить, что важным событием для будущего во всем мире стало принятие стандарта EMV (MasterCard/VISA), в котором содержится подробное описание работы кредитных карт.

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

==Технические особенности смарт-карт==
[[image:smart-card.png|border|300px|thumb|right]]
Смарт-карты имеют несколько преимуществ по сравнению с картами с магнитной полосой. Например, максимальная емкость памяти смарт-карты гораздо выше, чем у карты с магнитной полосой. Уже на сегодняшний день доступны чипы с емкостью памяти в мегабайтном размере, и значение максимальной емкости увеличивается с каждой усовершенствованной моделью чипа.
Однако одним из главных преимуществ смарт-карт является то, что данные внутри них могут быть защищены от неавторизированного доступа и манипуляций. Данные могут быть доступны только через последовательный интерфейс, подключенный к ОС. Таким образом, конфиденциальные данные будут безопасно храниться на чипе карты. В принципе, как аппаратные, так и программные механизмы наравне могут использоваться для ограничения функций памяти (чтение, запись…) и определенных состояний карты. Такая функциональность позволяет реализовывать различные механизмы безопасности согласно установленным требованиям приложения.
В сочетании со способностью вычисления криптографических алгоритмов, смарт-карты могут использоваться в качестве удобных модулей безопасности, легко хранимых на стороне пользователей, например, в качестве «кошелька». Другими дополнительными преимуществами смарт-карт является их высокая надежность и гарантированный период использования по отношению к картам с магнитной полосой (всего лишь 2-3 года).

==Типы смарт-карт==
Основные свойства и функции смарт-карт описываются в семействе стандартов ISO/IEC 7816. Смарт-карты разделяются на две группы: карты с памятью и карты с процессором.
Смарт-карты также могут классифицироваться по методам передачи данных. Данные могут передаваться с использованием механических контактов или без контактов (бесконтактные карты). Карты с памятью и процессорные карты доступны с поддержкой обоих вариантов.

====Карты с памятью====
[[image:smart-c-a.png|border|150px|thumb|right]]

Данные, необходимые для приложения, хранятся в энергонезависимой памяти (EEPROM). Доступ к памяти контролируется с помощью специально реализованной логики безопасности, которая в самом простом случае содержит только защиту от перезаписи. Однако, также доступны чипы памяти с более комплексными функциями безопасности, в которые входит, например, шифрование. Данные передаются с карты на последовательный интерфейс.
Функциональность карт с памятью обычно адаптирована под конкретные приложения. Хотя это ограничивает гибкие возможности таких карт, но делает их достаточно дешевыми.

====Бесконтактные карты с памятью====
[[image:sm-c-a2.png|border|150px|thumb|right]]
Бесконтактные карты с памятью стали широко распространены за последние годы. Стандартные карты разработаны в соответствии с ISO/IEC 14443. Используемый объем памяти в картах варьируется от нескольких сотен байт до нескольких килобайт. Дополнительно возможно разделение памяти на несколько секторов с возможностью отдельной защиты от несанкционированного доступа к каждому из них. Карта имеет свой уникальный серийный номер, хранимый в ROM, так же как и логику функции аутентификации с использованием метода «запрос-ответ».

====Процессорные карты====
[[image:sm-c-a3.png|border|150px|thumb|right]]
Ключевым компонентом такой карты является процессор (CPU). Архитектура процессорной карты показана на рисунке.
ROM содержит операционную систему, которая постоянно хранится в памяти чипа и не может быть перепрошита на протяжении всего жизненного цикла чипа. Информация в ROM является идентичной для всех типов чипов.
EEPROM – энергонезависимая память чипа. Данные и программный код записываются с помощью ОС в EEPROM для дальнейшего считывания. RAM – рабочая память процессора. Эта памяти энергозависима, поэтому все данные, хранящиеся в ней, потеряются в случае разрядки чипа.
Процессорные карты широко используются. В самом простом случае, они содержат программу, разработанную под конкретное приложение, что ограничивает функциональные возможности карты для использования в других приложениях.
Хотя современные ОС, используемые на смарт-картах позволяют использовать карты для различных задач. В таком случае ROM содержит только базовые компоненты ОС со специальными компонентами, загруженными в EEPROM, только после производства карты.

====Бесконтактные процессорные карты====
[[image:sm-c-a4.png|border|150px|thumb|right]]
Технология бесконтактных смарт-карт открывает новые возможности для поставщиков и пользователей. Например, бесконтактную карту не нужно вставлять в считыватель (card-reader), вместо этого ее необходимо только поднести близко к считывателю (радиус действия составляет около 10 см). Такая возможность удобна при использовании смарт-карт в системах физического контроля доступа (СКУД).

==Поставщики смарт-карт==
*[http://powersecurity.ru/ru/solutions/nids/ NagraID Display Security Card] от NIDSecurity
*[http://www.hidglobal.com/product-display/cards-and-credentials ActivID Security Smart-Cards] от HID Global
*[http://www.oracle.com/technetwork/java/javame/javacard/overview/getstarted/index.html JAVACARD]

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, Wolfgang Rankl, Wolfgang Effing]

Смарт-карта

2014-02-05T07:56:52Z

Korabelnikov: /* Поставщики смарт-карт */

[[image:sm-t.png|border|300px|thumb|right]]
'''Смарт-карта''' (от англ. '''Smart-Card''') – это пластиковая карта со встроенной микросхемой.
Смарт-карта является последним инновационным решением семейства идентификационных карт формата ID-1. Их характерной особенностью являются интегральные схемы, встроенные в корпус карты с компонентами для передачи, хранения и обработки информации. Данные могут передаваться на контакты карты или с помощью электромагнитного поля без использования контактов.

==История появления==
Технология смарт-карт прошла длительный путь становления. Ее история начинается с 1970-х годов, когда осуществлялись первые попытки внедрения энергонезависимой памяти и логики работы в чип карты, и продолжается вплоть до сегодняшнего дня.

Первоначально такая идея содержалась в заявке на патент от Юргена Детлоффа (Jürgen Dethloff) и Гельмута Гротруппа (Helmut Grötrupp) еще в 1968 году. Вслед за ними последовала похожая заявка от японца Kunitaka Arimure. Хотя реальное развитие смарт-карты получили во Франции в 1974 году, когда Роланд Морено (Roland Moreno) зарегистрировал свой патент на смарт-карту.

Первые пластиковые карты появились в 1950-х годах для осуществления безналичной оплаты. С момента вступления на рынок MasterCard и VISA, пластиковые карты стали быстро распространяться по всему миру. Первое поколение карт защищалось от подделки благодаря технологии безопасной печати и панелью подписи. Таким образом, безопасность карт полностью возлагалась на добросовестность и опыт сотрудников принимающих организаций.

Большой рост мошенничества привел к необходимости усовершенствования технологий безопасности. Первым улучшением стало появление магнитной полосы на обратной стороне карты. Следующим шагом стало использование [[PIN]]-кода (сравнивался с номером в терминале) для идентификации пользователя. Уязвимость магнитной полосы позволяла осуществлять действия (чтение/запись) с хранимыми на ней данными, что привело к необходимости хранения [[PIN]]-кодов в безопасной среде в защищенном виде.

Прорыв развития технологии смарт-карт был осуществлен в 1984-85 годах, когда во французских и немецких компаниях проводились тестовые испытания с телефонными картами. Результаты показали высокую надежность и безопасность смарт-карт. Хороший полученный опыт в аналоговых мобильных телефонных сетях оказал решающее значение для введения смарт-карт в цифровую сеть GSM.

Стоит отметить, что важным событием для будущего во всем мире стало принятие стандарта EMV (MasterCard/VISA), в котором содержится подробное описание работы кредитных карт.

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

==Технические особенности смарт-карт==
[[image:smart-card.png|border|300px|thumb|right]]
Смарт-карты имеют несколько преимуществ по сравнению с картами с магнитной полосой. Например, максимальная емкость памяти смарт-карты гораздо выше, чем у карты с магнитной полосой. Уже на сегодняшний день доступны чипы с емкостью памяти в мегабайтном размере, и значение максимальной емкости увеличивается с каждой усовершенствованной моделью чипа.
Однако одним из главных преимуществ смарт-карт является то, что данные внутри них могут быть защищены от неавторизированного доступа и манипуляций. Данные могут быть доступны только через последовательный интерфейс, подключенный к ОС. Таким образом, конфиденциальные данные будут безопасно храниться на чипе карты. В принципе, как аппаратные, так и программные механизмы наравне могут использоваться для ограничения функций памяти (чтение, запись…) и определенных состояний карты. Такая функциональность позволяет реализовывать различные механизмы безопасности согласно установленным требованиям приложения.
В сочетании со способностью вычисления криптографических алгоритмов, смарт-карты могут использоваться в качестве удобных модулей безопасности, легко хранимых на стороне пользователей, например, в качестве «кошелька». Другими дополнительными преимуществами смарт-карт является их высокая надежность и гарантированный период использования по отношению к картам с магнитной полосой (всего лишь 2-3 года).

==Типы смарт-карт==
Основные свойства и функции смарт-карт описываются в семействе стандартов ISO/IEC 7816. Смарт-карты разделяются на две группы: карты с памятью и карты с процессором.
Смарт-карты также могут классифицироваться по методам передачи данных. Данные могут передаваться с использованием механических контактов или без контактов (бесконтактные карты). Карты с памятью и процессорные карты доступны с поддержкой обоих вариантов.

====Карты с памятью====
[[image:smart-c-a.png|border|150px|thumb|right]]

Данные, необходимые для приложения, хранятся в энергонезависимой памяти (EEPROM). Доступ к памяти контролируется с помощью специально реализованной логики безопасности, которая в самом простом случае содержит только защиту от перезаписи. Однако, также доступны чипы памяти с более комплексными функциями безопасности, в которые входит, например, шифрование. Данные передаются с карты на последовательный интерфейс.
Функциональность карт с памятью обычно адаптирована под конкретные приложения. Хотя это ограничивает гибкие возможности таких карт, но делает их достаточно дешевыми.

====Бесконтактные карты с памятью====
[[image:sm-c-a2.png|border|150px|thumb|right]]
Бесконтактные карты с памятью стали широко распространены за последние годы. Стандартные карты разработаны в соответствии с ISO/IEC 14443. Используемый объем памяти в картах варьируется от нескольких сотен байт до нескольких килобайт. Дополнительно возможно разделение памяти на несколько секторов с возможностью отдельной защиты от несанкционированного доступа к каждому из них. Карта имеет свой уникальный серийный номер, хранимый в ROM, так же как и логику функции аутентификации с использованием метода «запрос-ответ».

====Процессорные карты====
[[image:sm-c-a3.png|border|150px|thumb|right]]
Ключевым компонентом такой карты является процессор (CPU). Архитектура процессорной карты показана на рисунке.
ROM содержит операционную систему, которая постоянно хранится в памяти чипа и не может быть перепрошита на протяжении всего жизненного цикла чипа. Информация в ROM является идентичной для всех типов чипов.
EEPROM – энергонезависимая память чипа. Данные и программный код записываются с помощью ОС в EEPROM для дальнейшего считывания. RAM – рабочая память процессора. Эта памяти энергозависима, поэтому все данные, хранящиеся в ней, потеряются в случае разрядки чипа.
Процессорные карты широко используются. В самом простом случае, они содержат программу, разработанную под конкретное приложение, что ограничивает функциональные возможности карты для использования в других приложениях.
Хотя современные ОС, используемые на смарт-картах позволяют использовать карты для различных задач. В таком случае ROM содержит только базовые компоненты ОС со специальными компонентами, загруженными в EEPROM, только после производства карты.

====Бесконтактные процессорные карты====
[[image:sm-c-a4.png|border|150px|thumb|right]]
Технология бесконтактных смарт-карт открывает новые возможности для поставщиков и пользователей. Например, бесконтактную карту не нужно вставлять в считыватель (card-reader), вместо этого ее необходимо только поднести близко к считывателю (радиус действия составляет около 10 см). Такая возможность удобна при использовании смарт-карт в системах физического контроля доступа (СКУД).

==Поставщики смарт-карт==
*[http://powersecurity.ru/ru/solutions/nids/ NagraID Display Security Card] от NIDSecurity
*[http://www.hidglobal.com/product-display/cards-and-credentials ActivID Security Smart-Cards] от HID Global
*[http://www.oracle.com/technetwork/java/javame/javacard/overview/getstarted/index.html JAVACARD]

==Источники==
#[http://it-ebooks.info/book/2705/| Smart Card Handbook, Wolfgang Rankl, Wolfgang Effing]

Облачные вычисления

2014-02-05T07:56:20Z

Korabelnikov:

'''Облачные вычисления''' (от англ. '''Cloud Computing''', жарг. рус. '''"Облака"''') – модель распределенных вычислений, которая сфокусирована на предоставлении доступа «по требованию» к масштабируемой, виртуализированной и/или программной инфраструктуре через сеть Интернет.

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

Одним из примеров облачных вычислений может служить использование электронной почты. Например, большинство компаний предпочитают настраивать почтовый сервер [http://office.microsoft.com/en-us/exchange/ Microsoft Exchange], в то время как «облачной» альтернативой может служить [https://mail.google.com Google Gmail].

==Модели облачных вычислений==

Облачные вычисления делятся на несколько классов услуг: SaaS, PaaS, IaaS.

====Программное обеспечение как услуга====
'''Программное обеспечение как услуга''' ('''Software as a Service''', '''SaaS''') – бизнес-модель продажи и использования программных продуктов, в которой облачный провайдер сам отвечает за разработку и установку ПО, а пользователь получает доступ к нему (например, через веб-интерфейс) в соответствии с приобретенной лицензией или лицензионным договором.
В качестве примера SaaS можно рассматривать продукт [http://powersecurity.ru/ru/solutions/opentrust/opentrust-mft/ OpenTrust MFT] от компании [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]. Решение предназначено для реализации безопасного обмена файлами и поставляется в двух вариантах: как дистрибутив ПО с соответствующей лицензий или как SaaS-услуга по лицензионному договору. Во втором случае пользователь получает доступ к веб-интерфейсу продукта, через который может осуществлять различные операции в соответствии с политикой доступа: загружать/отправлять файлы, управлять системой (администрирование) и пр.

====Платформа как услуга====
'''Платформа как услуга''' ('''Platform as a Service''', '''PaaS''') – бизнес-модель, при которой пользователю предоставляется возможность определять бизнес-логику работы приложения. Иными словами, PaaS обеспечивает комплексной платформой для разработки программного обеспечения, включая все необходимые для этой цели средства (создания, тестирования, выполнения; операционные системы, поддержку необходимых языков программирования и др.).
Примером PaaS являются [http://www.windowsazure.com/en-us/ Windows Azure] (Microsoft), Salesforce.com (SalesForce), AppEngine (Google).

====Инфраструктура как услуга====
'''Инфраструктура как услуга''' ('''Infrastructure as a Service''', '''IaaS''') – бизнес-модель, позволяющая пользователю управлять целой ИТ-инфраструктурой, включая вычислительную мощность, сетевые ресурсы и хранение данных.
Примером может служить Amazon Web Services, а именно платформы EC2 и Amazon S3, для размещения и запуска любого типа ПО за фиксированный промежуток времени. Причем потребитель таких услуг может иметь привилегии для настройки различных функций сервера: запуск и остановка, инсталляция дополнительных программных пакетов, подключение виртуальных дисков и конфигурирование политик доступа и правил МЭ.

==Источники==
#[http://s3.amazonaws.com/academia.edu.documents/30948841/intro.pdf?AWSAccessKeyId=AKIAIR6FSIMDFXPEERSA&Expires=1379494744&Signature=nqgVY556JClD%2ByCgZpCjk6Mw6mY%3D&response-content-disposition=inline Chapter 1. INTRODUCTION TO CLOUD COMPUTING бWILLIAM VOORSLUYS, JAMES BROBERG, and RAJKUMAR BUYYA]
#[http://www.lbcloudcomputing.com/Cloudcomputingbasics.pdf Basics about cloud computing, Grace Lewis]

MFT

2014-02-05T07:54:22Z

Korabelnikov: /* Источники */

'''Управляемая передача файлов''' (англ. ''Managed File Transfer, MFT'') – программное решение, реализованное для упрощения задач передачи файлов с одного компьютера на другой посредством сети (например, через Интернет).

MFT предоставляется клиенту, как правило, в двух возможных вариантах: либо как лицензионный дистрибутив ПО, либо как облачное решение (SaaS).

==Предпосылки==
Увеличение роста и объема информационных потоков привело к тому, что передача информации стала неотъемлемой частью бизнес-процессов большинства структур. Появилась необходимость обмена файлами и электронными документами между различными категориями пользователей: как между сотрудниками в рамках компании, так и между сотрудниками и внешними партнерами/клиентами.
Использование традиционных решений, как, например, электронная почта и FTP, больше не могут покрыть весь спектр требований, которые необходимы для реализации подсистемы безопасности компании с целью предотвращения утечки конфиденциальных данных. Более того, подобные ресурсы не способны обеспечить комплексной защитой передаваемые файлы, гарантировать конфиденциальность информации и контролировать процесс обмена. Сложившаяся ситуация привела к увеличению спроса на продукты типа MFT.

==Задачи==
MFT покрывает такие задачи, как:

#Автоматизация передачи данных;
#Безопасный и авторизованный обмен данными;
#Обеспечение конфиденциальности передаваемой информации;
#Обеспечение целостности файлов;
#Управление пользователями и группами пользователей;
#Простой интерфейс управления;
#Поддержка различных методов аутентификации;
#Интеграция с существующими информационными системами (ИС).

==Ключевые функции MFT==

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

#Шифрование отправляемых файлов;
#Проставление ЭЦП на передаваемых документах;
#Аудит проделанных операций и входов в систему;
#Администрирование системы;
#Журналирование;
#Возможность интеграции с различными ИС с помощью API;
#Возможность аутентификации на основе LDAP, AD, Web SSO, X.509 и др.

==Сценарии передачи файлов==
Существует как минимум три сценария передачи данных между пользователями:

*Регулярный обмен файлами;
*Периодическая передача по схеме «система-система»/«приложение-приложение»;
*Периодическая передача по схеме «участник-участник».

Выбор определенной схемы зависит от поставленных целей и задач компании, в которой требуется организовать безопасный и управляемый обмен.

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

С некоторыми допущениями предположим, что есть определенная компания, которая занимается продажами продуктов/оборудования зарубежных партнеров. Компания не имеет своего собственного склада, а оформляет заказ напрямую у партнера в соответствии с требованиями локального заказчика. После оформления соответствующая информация и все документы о закупке должны быть переданы потенциальному клиенту. В данном случае организация должна обеспечить полностью безопасную передачу подписанных отгрузочных документов между зарубежным партнером и заказчиком. Такая функциональность, как правило, входит в продукты MFT.

====Периодическая передача по схеме «система-система»/«приложение-приложение»====
Предположим, что существует две аффилированные организации, в информационной среде которых установлены модули консолидированной системы сбора и хранения информации. В такую систему поступают данные различных категорий, например, лог-файлы подсистемы аудита, данные о зарегистрированных пользователях, файлы с отчетами пользователей о проделанной работе и другая информация. С помощью продуктов MFT с соответствующим функционалом существует возможность автоматической генерации и передачи отдельного файла из одного модуля системы в другой безопасным способом.

====Периодическая передача по схеме «участник-участник»====
Данная схема особенно распространена в случаях обмена информацией между внутренними сотрудниками и/или между департаментами организации. Примером может служить медицинское учреждение, где врачи могут осуществлять передачу электронных карточек пациентов, больничные листы и прочую информацию для ознакомления и дальнейшей работы своим коллегами или другим департаментам.

==Поставщики продуктов MFT==
Существует достаточное большое количество поставщиков программных решений для управляемого обмена данными, примером которых могут быть: [http://powersecurity.ru/ru/solutions/opentrust/opentrust-mft/?preview OpenTrust MFT] от компании [[OpenTrust|Keynetis-OpenTrust]], [http://www-01.ibm.com/software/ru/commerce/managed-file-transfer/ Sterling Managed File Transfer] от компании IBM, [http://www.policypatrol.com/news/policy-patrol-mft-offers-instant-trackable-and-secure-file-transfer/ Policy Patrol MFT] от компании Red Earth Software, [http://www.attunity.com/company Attunity MFT] от компании Attunity.

==Источники==
#[http://www.google.ru/books?hl=en&lr=&id=0QlDrIfBn68C&oi=fnd&pg=PR1&dq=managed+file+transfer+mft&ots=R2DOOycjK3&sig=QJPV0lReWOeMueHXinqccAFQZIw&redir_esc=y#v=onepage&q&f=false Secure Managed File Transfer] by Don Jones.
#[http://www.itjungle.com/fhs/fhs090109-story01.html Managed File Transfer: A New Product Category That's Here to Stay] by Alex Woodie
#[http://davidjwalling.com/lab_omtmft.html Optimizing Multitenant Managed File Transfer, Part One: Concepts and Approaches] by David J. Walling

CMS

2014-02-05T07:53:11Z

Korabelnikov: /* Источники */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*HSM;
*Пользовательские директории;
*Принтер для смарт-карт;
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-smartact/ Nexus SmartACT] от [http://powersecurity.ru/ru/solutions/nexussafe/ Nexus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/ Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf Applied Cryptography, Bruce Schneier]

CMS

2014-02-05T07:53:00Z

Korabelnikov: /* Существующие решения */

'''Система управления картами''' (от англ. (Smart) '''Card Management System''', сокр. '''SCMS''', '''CMS''') – это система, предназначенная для управления смарт-картами. CMS работает со смарт-картами на протяжении всего жизненного цикла, начиная с их выпуска и поддержки в процессе эксплуатации до утилизации. Как правило, к подобным системам выдвигаются серьезные требования по обеспечению безопасности благодаря использованию в CMS различного рода важной информации, например, такой, как учетные данные пользователей или [[PIN]]-коды к существующим картам.

==Работа со смарт-картами==
====Назначение смарт-карт====
Смарт-карты играют роль безопасного хранилища (например, цифровых сертификатов) и представляют собой некий аналог учетных данных, необходимых для идентификации пользователя в системе (например, использование [[Строгая аутентификация| двухфакторной аутентификации]]).

====Использование смарт-карт====
*аутентификация пользователя в системе;
*физический доступ к объекту;
*логический доступ к компьютеру, корпоративным сетям и/или другим ресурсам;
*проставление ЭЦП на документах;
*защита электронной почты;
*др.

====Жизненный цикл смарт-карт====
На протяжении всего жизненного цикла, смарт-карта меняет свое состояние, поэтому ключевой задачей CMS является перевод карты из одного состояния в другое. Под термином «состояние» понимается некая операция, производимая с картой (обновление, инициализация, блокировка, …).

====Список возможных состояний смарт-карты в системе====
#Зарегистрирована;
#Выпущена;
#Инициализована/Переинициализирована;
#Активирована;
#Деактивирована;
#Заблокирована;
#Разблокирована;
#Отозвана;
#Восстановлена;
#Создана резервная копия.

==CMS как программное обеспечение==
В большинстве случаев системы управления смарт-картами реализуются в виде программного продукта. Причем, зачастую, доступ к системе должен осуществляться более, чем одним оператором/пользователем одновременно. Поэтому, очень часто CMS встречается в виде клиент-серверной модели приложения.

==Интеграция с другими системами==
Системы управления смарт-картами интегрируются с различными системами, которые также используются для работы со смарт-картами.
Примеры подключаемых систем:
*Контактный/бесконтактный ридер;
*Удостоверяющий Центр;
*HSM;
*Пользовательские директории;
*Принтер для смарт-карт;
*Системы физического доступа.

==Существующие решения==
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS] от [http://powersecurity.ru/ru/solutions/opentrust/ OpenTrust]
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-smartact/ Nexus SmartACT] от [http://powersecurity.ru/ru/solutions/nexussafe/ Nexus Technology]
*[http://www.hidglobal.com/products/appliances/activid/activid-credential-management-system ActivID CMS] от [http://www.hidglobal.com/ HID Global]
*[http://www.gemalto.com/products/das/ DAS] от Gemalto
*[http://www.intercede.com/products/myid.aspx MyID CMS] от Intercede
*[http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx Forefront Identity Manager 2010 R2] от Microsoft

==Источники==
#[http://it-ebooks.info/book/2705/| Smart Card Handbook, 4th Edition, Wolfgang Rankl and Wolfgang Effing]
#[http://www.cse.iitk.ac.in/users/anuag/crypto.pdf| Applied Cryptography, Bruce Schneier]

PKI

2014-02-05T07:50:06Z

Korabelnikov: /* Источники */

[[image:PKI.png|border|300px|thumb|right]]
Криптография на основе открытых ключей, пожалуй, является одним из наиболее практичных инновационных решений в области математики 20 века, которое оказало огромное влияние на технологии компьютерной безопасности. Инфраструктура открытых ключей (ИОК, PKI, Public Key Infrastructure) – гибкая и масштабируемая инфраструктура для организации безопасной идентификации, аутентификации, обеспечения конфиденциальности и целостности данных в процессе взаимодействия (обмена данными) или получения каких-либо услуг. В эпоху глобальных коммуникаций и стремительного развития всемирной сети Интернет и мобильных сервисов, PKI предложило общие механизмы безопасности для применения в различных типах приложений и является неизбежным с точки зрения реализации в определенных сферах применения. Инфраструктура открытых ключей обеспечивает пользователей электронными идентификаторами (цифровыми сертификатами), включая управление и подтверждение состояния актуальности на протяжении всего жизненного цикла. Электронные идентификаторы могут рассматриваться в качестве неких «пользовательских паспортов», с помощью которых пользователи смогут получить доступ к определенным ресурсам, вести важную переписку в корпоративной или публичной сети или проводить дорогостоящие электронные транзакции.

==Основная концепция==
'''Инфраструктура открытых ключей (ИОК)''' – это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных системах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах жизненного цикла, обеспечивая взаимодействие всех средств защиты распределенной системы.

Инфраструктура открытых ключей является самой гибкой, масштабируемой и безопасной технологией, которая обеспечивает пользователей информации и информационных систем (люди и устройства) цифровыми идентификаторами (сертификатами). Пользователи могут использовать цифровые сертификаты для решения различных задач: аутентификация, цифровая подпись и шифрование. В PKI у каждого пользователя есть ключевая пара и сертификат. Ключ является последовательностью цифровых данных и используется для осуществления криптографических операций таких, как подписание и шифрование. Ключевая пара состоит из открытого и закрытого ключей, где закрытый ключ является неким «секретом» и хранится только в устройстве пользователя (смарт-карте, ПК, телефоне или др.). Благодаря тому, что закрытый ключ невозможно вычислить из соответствующего ему открытого ключа, последний публично известен. Сертификат хранит в себе пользовательские данные, какую-либо проверочную информацию и сам открытый ключ и располагается в идентификационной карте пользователя. Удостоверяющий центр (УЦ) осуществляет подписание и публикацию сертификата. Подпись УЦ доказывает наличие у пользователя пары ключей.

==Основные функции PKI==
*Аутентификация пользователей;
*Проверка валидности сертификатов;
*Обеспечение целостности данных;
*Неотказуемость;
*Конфиденциальность.

==Ключевые принципы PKI==
*Только владелец знает о своем закрытом ключе;
*УЦ генерирует сертификат открытого ключа, что позволяет удостоверить данный ключ;
*Доверие выстраивается только между владельцами сертификатов (пользователями) и УЦ, но друг с другом;
*Проверка (подтверждение/отказ) принадлежности открытого ключа заданному пользователю осуществляется УЦ.

==Участники инфраструктуры PKI==

'''Центр Регистрации''' (Регистрационный Центр) – компонент системы, являющийся не обязательной ее частью, который предназначен для регистрации пользователей.

'''Центр Сертификации''' (Удостоверяющий Центр) – организация или ее подразделение, выдающая сертификаты открытого ключа электронной цифровой подписи и управляющая криптографическими ключами пользователей.

'''Узел''' – наименьшая структурная единица в сети. Узел представляет собой компьютер конечного пользователя.

'''Сертификат ключа подписи''' - документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику информационной системы для подтверждения подлинности электронной цифровой подписи и идентификации владельца сертификата ключа подписи.

'''Хранилище сертификатов''' (Репозиторий) – хранилище цифровых сертификатов и списков отозванных сертификатов, служащее также средством распространения между пользователями системы.

'''Архив сертификатов''' – хранилище цифровых сертификатов, в котором располагаются все когда-либо изданные сертификаты с целью проверки ранее подписанных ЭЦП документов.

'''Центр запросов''' – компонент системы, с помощью которого пользователи системы смогут отправить запрос или отозвать действующий сертификат.

==Цифровой сертификат==
включает в себя:
*Идентификационные данные о владельце сертификатa;
*Уникальный открытый ключ владельца сертификата;
*Срок действия сертификата;
*Цифровую подпись УЦ.

==Ключевые решения на рынке==
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-certificate-manager/ Nexus Certificate Manager];
*[http://www.cryptopro.ru/products/ca КриптоПро УЦ];
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-pki/ OpenTrust PKI];
*Microsoft CA;
*Rsa Keon.

==Источники==
#Запечников С. В. Криптографические протоколы и их применение в финансовой и коммерческой деятельности. Горячая линия – Телеком, 2007. – 320 с.
#Полянская О. Ю., Горбатов В. С. Инфраструктура открытых ключей. Учебное пособие., Москва, 2007.
#[http://www.nexusgroup.com/Documents/SolutionBriefs_eng/neXus-PKI-Solution-Brief.pdf NeXus PKI Solution Brief]. Краткое техническое описание компании NeXus.
#[http://base.garant.ru/184059/1/#block_100 ФЗ №1 «Об электронной цифровой подписи.»]

PKI

2014-02-05T07:49:48Z

Korabelnikov: /* Ключевые решения на рынке */

[[image:PKI.png|border|300px|thumb|right]]
Криптография на основе открытых ключей, пожалуй, является одним из наиболее практичных инновационных решений в области математики 20 века, которое оказало огромное влияние на технологии компьютерной безопасности. Инфраструктура открытых ключей (ИОК, PKI, Public Key Infrastructure) – гибкая и масштабируемая инфраструктура для организации безопасной идентификации, аутентификации, обеспечения конфиденциальности и целостности данных в процессе взаимодействия (обмена данными) или получения каких-либо услуг. В эпоху глобальных коммуникаций и стремительного развития всемирной сети Интернет и мобильных сервисов, PKI предложило общие механизмы безопасности для применения в различных типах приложений и является неизбежным с точки зрения реализации в определенных сферах применения. Инфраструктура открытых ключей обеспечивает пользователей электронными идентификаторами (цифровыми сертификатами), включая управление и подтверждение состояния актуальности на протяжении всего жизненного цикла. Электронные идентификаторы могут рассматриваться в качестве неких «пользовательских паспортов», с помощью которых пользователи смогут получить доступ к определенным ресурсам, вести важную переписку в корпоративной или публичной сети или проводить дорогостоящие электронные транзакции.

==Основная концепция==
'''Инфраструктура открытых ключей (ИОК)''' – это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных системах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах жизненного цикла, обеспечивая взаимодействие всех средств защиты распределенной системы.

Инфраструктура открытых ключей является самой гибкой, масштабируемой и безопасной технологией, которая обеспечивает пользователей информации и информационных систем (люди и устройства) цифровыми идентификаторами (сертификатами). Пользователи могут использовать цифровые сертификаты для решения различных задач: аутентификация, цифровая подпись и шифрование. В PKI у каждого пользователя есть ключевая пара и сертификат. Ключ является последовательностью цифровых данных и используется для осуществления криптографических операций таких, как подписание и шифрование. Ключевая пара состоит из открытого и закрытого ключей, где закрытый ключ является неким «секретом» и хранится только в устройстве пользователя (смарт-карте, ПК, телефоне или др.). Благодаря тому, что закрытый ключ невозможно вычислить из соответствующего ему открытого ключа, последний публично известен. Сертификат хранит в себе пользовательские данные, какую-либо проверочную информацию и сам открытый ключ и располагается в идентификационной карте пользователя. Удостоверяющий центр (УЦ) осуществляет подписание и публикацию сертификата. Подпись УЦ доказывает наличие у пользователя пары ключей.

==Основные функции PKI==
*Аутентификация пользователей;
*Проверка валидности сертификатов;
*Обеспечение целостности данных;
*Неотказуемость;
*Конфиденциальность.

==Ключевые принципы PKI==
*Только владелец знает о своем закрытом ключе;
*УЦ генерирует сертификат открытого ключа, что позволяет удостоверить данный ключ;
*Доверие выстраивается только между владельцами сертификатов (пользователями) и УЦ, но друг с другом;
*Проверка (подтверждение/отказ) принадлежности открытого ключа заданному пользователю осуществляется УЦ.

==Участники инфраструктуры PKI==

'''Центр Регистрации''' (Регистрационный Центр) – компонент системы, являющийся не обязательной ее частью, который предназначен для регистрации пользователей.

'''Центр Сертификации''' (Удостоверяющий Центр) – организация или ее подразделение, выдающая сертификаты открытого ключа электронной цифровой подписи и управляющая криптографическими ключами пользователей.

'''Узел''' – наименьшая структурная единица в сети. Узел представляет собой компьютер конечного пользователя.

'''Сертификат ключа подписи''' - документ на бумажном носителе или электронный документ с электронной цифровой подписью уполномоченного лица удостоверяющего центра, которые включают в себя открытый ключ электронной цифровой подписи и которые выдаются удостоверяющим центром участнику информационной системы для подтверждения подлинности электронной цифровой подписи и идентификации владельца сертификата ключа подписи.

'''Хранилище сертификатов''' (Репозиторий) – хранилище цифровых сертификатов и списков отозванных сертификатов, служащее также средством распространения между пользователями системы.

'''Архив сертификатов''' – хранилище цифровых сертификатов, в котором располагаются все когда-либо изданные сертификаты с целью проверки ранее подписанных ЭЦП документов.

'''Центр запросов''' – компонент системы, с помощью которого пользователи системы смогут отправить запрос или отозвать действующий сертификат.

==Цифровой сертификат==
включает в себя:
*Идентификационные данные о владельце сертификатa;
*Уникальный открытый ключ владельца сертификата;
*Срок действия сертификата;
*Цифровую подпись УЦ.

==Ключевые решения на рынке==
*[http://powersecurity.ru/ru/solutions/nexussafe/nexus-certificate-manager/ Nexus Certificate Manager];
*[http://www.cryptopro.ru/products/ca КриптоПро УЦ];
*[http://powersecurity.ru/ru/solutions/opentrust/opentrust-pki/ OpenTrust PKI];
*Microsoft CA;
*Rsa Keon.

==Источники==
#Запечников С. В. Криптографические протоколы и их применение в финансовой и коммерческой деятельности. Горячая линия – Телеком, 2007. – 320 с.
#Полянская О. Ю., Горбатов В. С. Инфраструктура открытых ключей. Учебное пособие., Москва, 2007.
#[http://www.nexusgroup.com/Documents/SolutionBriefs_eng/neXus-PKI-Solution-Brief.pdf| NeXus PKI Solution Brief]. Краткое техническое описание компании NeXus.
#[http://base.garant.ru/184059/1/#block_100| ФЗ №1 «Об электронной цифровой подписи.»]

MFT

2013-09-17T11:22:23Z

Korabelnikov: /* Предпосылки */

Out-of-band

2013-08-13T15:32:30Z

Korabelnikov:

В аутентификации термин '''out-of-band''' означает использование независимого (альтернативного) канала (связи). Идея заключается в том, что в процессе аутентификации используется дополнительный канал связи, по которому передаются данные аутентификации или параметры подписи транзакции.
Атаки нацелены на основной канал, который используется в процессе выполнения транзакции и аутентификации, а использование второго нескомпрометированного канала позволяет разделить полезные данные (транзакционные) и данные аутентификации.

Наиболее распространенным альтернативным каналом является канал сотовой связи, по которому высылается одноразовый пароль в виде SMS, передаются код подтверждения транзакции вместе с основными параметрами транзакций. В качестве примера можно привести онлайн сервисы, предоставляемые банками: клиенты банка осуществляют подключение к онлайн сервисам используя логин и [[одноразовый пароль]], который отправялется на их мобильный телефон в виде SMS-сообщения. Основной канал - широкополосный доступ в итнернет, благодаря которому в браузере пользователя отображается окно входа, второй независимый канал - мобильная сеть.

Как развитие этого направления на мобильный телефон может быть установлено специальное программное обеспечение, которое взаимодействует с [[Сервер Аутентификации|сервером аутентификации]] и авторизации для получения кодов авторизации и данных проводимой транзакции. Такой вариант более надежен, так как подразумевает шифрование канала связи мобильным устройством и сервером, а также имеет дополнительный уровень защиты в виде [[PIN|PIN]]-кода или пароля

OATH

2013-08-13T15:26:17Z

Korabelnikov:

'''OATH''' (Open AuTHentication, [http://www.openauthentication.org]) — международная инициативная группа, состоящая из разработчиков систем строгой аутентификации, основной целью которой являются стандартизация (разработка стандартов на уровне RFC) алгоритмов генерации одноразовых паролей ([[одноразовый пароль|OTP, one-time password]]) и разработка архитектуры решения. Основная идея — обеспечить полную совместимость компонентов решения по [[строгая аутентификация|строгой аутентификации]] разных производителей. Для формализации этой задачи разработана Программа OATH-Сертификации (OATH Certification Program [http://www.openauthentication.org/certification]).

В инициативную группу OATH входят такие компании, как [http://powersecurity.ru/ru/solutions/nexussafe/ Nexus(PortWise)], [http://powersecurity.ru/ru/solutions/nids/ Nagra ID], ActivIdentity, Entrust, Gemalto, Lieberman Software, N-Crypt, Symantec, SanDisk, TotalTexto, VeriSign и другие.

Основные наработки:

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по событию (event-base) — [[HOTP]], описан в виде RFC 4226

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по времени (time-base) — [[TOTP]], описан в виде RFC 6238

*Асинхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] в режиме запрос-ответ (challenge-response) — [[OCRA]], описан в виде RFC 6287

*Стандарт конфигурационного файла генератора [[одноразовый пароль|одноразовых паролей]] (переносимый контейнер симметричного колюч) — PSKC (Portable Symmetric Key Container), описан в виде RFC 6030

Кроме того было разработано описание архитектуры в виде документа OATH Reference Architecture (текущая версия — вторая) [http://www.openauthentication.org/webfm_send/1]

OpenTrust

2013-08-13T14:31:43Z

Korabelnikov: /* Российские смарт-карты */

OpenTrust ([http://www.keynectis.com/en Keynectis])

==История==

Французская компания, начавшая свою работу как системный интегратор, специализирующийся на внедрении решений в области [http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%8B%D1%85_%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%B9 инфраструктуры открытых ключей (PKI)] на базе open-source продуктов.
В процессе реализации таких проектов каждый раз выполнялась серьёзная доработка используемого решения под требования заказчика, что привело к накоплению достаточно большого перечня, скажем так, дополнительного функционала, надстраиваемого над бесплатным и открытым PKI-движком.
Накопленный опыт, оттачиваемый от проекта к проекту и постоянно расширяемый функционал сподвиг копанию-интегратор к вполне видимому шагу: стать вендором коммерческого PKI-решения и переместиться из системной интеграции в область разработки, оставив при этом в своем портфеле услуги по внедрению своих же продуктов ([http://powersecurity.ru/ru/needs/ professional services]).

До недавнего времени учредителями компании OpenTrust были частные инвесторы, [http://www.Gemalto.com Gemalto] и государственные компании Франции. Не так давно компания OpenTrust была приобретена государственной компанией Франции [http://www.keynectis.com/en Keynectis], специализирующейся в разработке, поставке и внедрении специфических PKI-систем для государственных структур, в первую очередь Франции (в частности [http://www.keynectis.com/en Keynectis] специализируется в области комплексных решений для инфраструктуры электронных паспортов).

Существует мнение, что в ближайшее время OpenTrust полностью ассимилирует в эко-системе [http://www.keynectis.com/en Keynectis], включая полный ребрендинг разрабатываемых продуктов.

==Продукты и решения OpenTrust (Keynectis)==
Ожидаемым шагом, после запуска коммерческой версии PKI (OpenTrust PKI) стала разработка коммерческой версии системы управления жизненным циклом смарт-карт OpenTrust CMS, которая поддерживает все востребованные модели смарт-карт и usb-токенов на нативном уровне (что есть очень хорошо).
Третьим продуктом стала система защищенного (управляемого) файлобмена — OpenTrust MFT (Managed File Transfer).

Вполне понятно (к этому обязывают истоки компании и это хорошо), что все продукты компании OpenTrust работают под управлением [http://www.linux.org/ Linux].

==Заслуги и прочие медальки==
Очевидной заслугой, которую можно приписать OpenTrust (что бы там не говорили всякие и разные) — это авторство концепции Next-Generation PKI, которая влила новые свежую кровь в эту технологию, скажем так, с бородой.

==Российский рынок==
На российском рынке компания OpenTrust делает уверенные шаги, которые заключаются в первую очередь в адаптации продуктов к Российским реалиям.

===Российская криптография===
По понятным причинам PKI-решение необходимо ГОСТифицировать. Что и было успешно реализовано. Так как в основе движка лежит OpenSSL, задача решалась именно в этом направлении: была проведена совместная работа с компанией [http://cryptocom.ru/ КриптоКом] (активным участником [http://cryptocom.ru/opensource/ open source] проекта [http://cryptocom.ru/opensource/openssl100.html openSSL], разработчиком [http://cryptocom.ru/solutions/index.html сертифицированных СКЗИ]) по интеграции сертифицированного криптомодуля реализующего ГОСТовые алгоритмы в [http://openssl.org/ openSSL].

===Российские смарт-карты===
Так как таковых нет, а есть Российские usb-токены, то была проведена реализована поддержка управления их жизненным циклом в соответствующей системе — [http://powersecurity.ru/ru/solutions/opentrust/opentrust-cms/ OpenTrust CMS]. Речь, понятно, идет о [http://www.rutoken.ru/ ruToken (руТокен)] производства Актив (Актив-Софт). Другой, очень популярный в России производитель как смарт-карт, так и usb-токенов [http://Aladdin-rd.ru Aladdin] ныне [http://safenet-inc.com SafeNet] с решениями [http://www.aladdin-rd.ru/catalog/etoken/ eToken] поддерживается давно и очень активно, но не благодаря попыткам закрепиться на российском рынке, а из-за мировой популярности этого решения, которое у нас стало практически именем нарицательным

===Российская криптография (2)===
Она же, как и в PKI тем же самым путем была реализована в MFT (что хорошо)

===Сертификация===
Делаются определенные потуги по сертификации некоторых продуктов в некоторых органах, [http://fsb.ru/ authority], так сказать. Пожелаем им успехов!

HOTP

2013-08-13T14:16:14Z

Korabelnikov: /* Требования */

==HOTP: общее описание==

'''HOTP''' — [[OATH]]-алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации [[одноразовый пароль|одноразового пароля]]: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это динамическое значение используется как основной параметр при расчете одноразового пароля.

Вторым параметром, используемым при расчете [[одноразовый пароль|одноразовых паролей]], является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора [[одноразовый пароль|одноразовых паролей]]. При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событий, который вместе с симметричным ключом «прошивается» в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).

== О чем думали создатели алгоритма==

Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет не столько о совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)

Детализированные требования можно прочитать в RFC 4226, здесь же приведем их короткие трактовки:

#В основе алгоритма должна быть последовательность, то есть он должен основываться на счетчике событий
#Должен быть экономичным с точки зрения вычислительных мощностей, энергопотребления, интерфейса взаимодействия с пользователем (минимизация количества кнопок и пр.)
#Не должен требовать ввода каких-либо значений
#Простота восприятия пользователем: значение должно быть числовым с длиной минимум 6 цифр
#Простота ре-синхронизации счетчика событий
#Должен использовать надёжный общий секрет (shared secret) длина которого должна быть не менее 128 бит, а рекомендованная длина — 160 бит

==Проверка одноразового пароля и прочие радости==

=== Проверка===
Генератор (клиент, в [[OATH]]-терминологии) увеличивает значение своего счетчика на единицу каждый раз, когда инициируется генерация одноразового пароля (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора).
Это значение передается на сервер аутентификации (сервер проверки, в [[OATH]]-терминологии) и сравнивается со значением рассчитанным сервером. Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу.
Если значения, полученные и рассчитанные сервером не совпали, сервер инициирует процесс ресинхронизации (в пределах допустимого окна рассинхронизации — параметр s).
Если процесс ресинхронизации не удался, сервер инициирует запрос другого значения одноразового пароля.
Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной записи пользователя)

===Рассинхронизация счетчика===
[[OATH]]-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимость синхронности значений счетчика событий, используемого генератором (клиентом) и сервером в процессе расчета и проверки одноразового пароля.
Как сказано выше инкремент счетчика генератора выполняется каждый раз, когда выполняется генерация одноразового пароля. В то же время инкремент счетчика на сервере выполняется только в случае успешной аутентификации. Исходя из этого можно выделить несколько наиболее вероятных причин ресинхронизации:
#Аутентификация не пройдена. Генератор инкрементировал свой счётчик, а сервер нет.
#Проблема связи. Генератор инкрементировал свой счётчик, а север не получил одноразовый пароль. В этом случае при невнятном сообщении об ошибке пользователь с высокой вероятностью выполнит повторную генерацию одноразового пароля.
#Элементарное баловство :)

===Ресинхронизация счетчика===

Ресинхронизация выполняется расчетом следующего HOTP-значения и сравнением с полученным от клиента (генератора). Это повторяется в переделах заданного окна ресинхронизации s. Дополнительно в процессе ресинхронизации сервер может запросить дополнительные значения одноразовых паролей (2 или 3). Это сделано для повышения безопасности, так как сравнения в этом случае выполняется для двух или трех пар, и все они должны пройти успешно.
Параметр s — определяет окно, в пределах которого сервер увеличивать счетчик в процессе ресинхронизации.

Это ограничение вводится по двум причинам:

#ограничить вероятность подбора одноразового значения (см ниже расчет вероятности)
# предотвратить бесконечный расчет в рамках одной проверки и как следствие отказ в обслуживании

==Математическая подоплека==

===Общее===
В основе генерации одноразовых паролей лежит HMAC-функция, на вход которой подается два значения: симметричный ключ и текущее состояние счетчика. Отсюда, кстати, и название алгоритма HOTP — HMAC-Based One-Time Password. В качестве основы HMAC взят алгоритм SHA-1 (RFC 3174), то есть речь идет о HMAC-SHA-1 (RFC 2104) с длиной результата 160 бит.

Так как конечный пользователь будет испытывать катастрофические затруднения при наборе одноразового пароля длиной 160 бит, алгоритм предусматривает обрезку оригинального результата (160 бит) до приемлемой длины: одноразовый пароль имеет формат цифрового значения с длиной не менее 6 символов (цифр).
Таким образом, функция генерации одноразового пароля по событию записывается следующим образом:

<center>HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))</center>

где:

К — симметричный ключ

С — текущее состояние счетчика

T — количество неверных аутентификаций, после которых сервер заблокирует учетную запись пользователя

s — параметр рассинхронизации, определяет максимальное расхождение между счетчиком сервера и генератора (клиента в [[OATH]]-терминологии), при котором одноразовый пароль будет принят.

Digit — количество цифр в значении одноразового пароля

Truncate — функция обрезки, позволяющая преобразовать 160-битное значение функции HMAC-SHA-1, в упомянутый выше юзер-френдли числовой формат (с длиной 6 или более символов)

===Как работает Truncate (обрезка)===

Результат HMAC-SHA-1 (RFC 2104)— 160 бит или строка, состоящая из 20 байт, на основе чего генерируется строка в 4 байта. Это происходит следующим образом:

20-байтная строка представляется как 20 блоков по 8 бит, 4 младших бита последней 20-ой 8-битной последовательности определяют смещение (понятно, что это значение находится в диапазоне от 0 до 15). Далее выполняется конкатенация (склеивание) 4 последовательностей, первая из которых является строковым предобразованием вычисленного смещения, а вторая — преобразованием от смещения увеличенного на единицу и т.д. последние 31 бита этой склейки и будут теми 4 байтами.

Далее 4 байта представляются как десятичное число, которое делится по модулю на 10^Digit. Результат и есть одноразовый пароль

==Аспекты безопасности==

===Надежность алгоритма===

Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).
Легко понять, что вероятность прохождения аутентификации будет считаться по формуле:

<center>Sec = sT/10^Digit</center>

где:

Sec — рассчитываемая вероятность

s — окно допустимой расссинхронизации счетчиков на сервере и клиенте (генераторе)

T — количество попыток пройти аутентификации, при достижении которого учетная запись пользователя блокируется

Digit — количество цифр в одноразовом пароле.

Например, при 5 разрешенных попытках, окне допустимом окне рассинхронизации равном 30 и 6-цифровом одноразовом пароле, вероятность подобрать пароль составит и пройти аутентификацию составит: 0.015%

===Требования===

#Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым - некоторый дополнительный секрет, который добавляется к одноразовому паролю.
#Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае) должна блокироваться после определенного числа неуспешных попыток аутентификации
#Необходимо использовать защищенный канал

HOTP

2013-08-13T14:15:25Z

Korabelnikov: много грамматических исправлений

==HOTP: общее описание==

'''HOTP''' — [[OATH]]-алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации [[одноразовый пароль|одноразового пароля]]: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это динамическое значение используется как основной параметр при расчете одноразового пароля.

Вторым параметром, используемым при расчете [[одноразовый пароль|одноразовых паролей]], является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора [[одноразовый пароль|одноразовых паролей]]. При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событий, который вместе с симметричным ключом «прошивается» в генератор и записывается в конфигурационный файл (по [[OATH]]-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).

== О чем думали создатели алгоритма==

Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет не столько о совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)

Детализированные требования можно прочитать в RFC 4226, здесь же приведем их короткие трактовки:

#В основе алгоритма должна быть последовательность, то есть он должен основываться на счетчике событий
#Должен быть экономичным с точки зрения вычислительных мощностей, энергопотребления, интерфейса взаимодействия с пользователем (минимизация количества кнопок и пр.)
#Не должен требовать ввода каких-либо значений
#Простота восприятия пользователем: значение должно быть числовым с длиной минимум 6 цифр
#Простота ре-синхронизации счетчика событий
#Должен использовать надёжный общий секрет (shared secret) длина которого должна быть не менее 128 бит, а рекомендованная длина — 160 бит

==Проверка одноразового пароля и прочие радости==

=== Проверка===
Генератор (клиент, в [[OATH]]-терминологии) увеличивает значение своего счетчика на единицу каждый раз, когда инициируется генерация одноразового пароля (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора).
Это значение передается на сервер аутентификации (сервер проверки, в [[OATH]]-терминологии) и сравнивается со значением рассчитанным сервером. Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу.
Если значения, полученные и рассчитанные сервером не совпали, сервер инициирует процесс ресинхронизации (в пределах допустимого окна рассинхронизации — параметр s).
Если процесс ресинхронизации не удался, сервер инициирует запрос другого значения одноразового пароля.
Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной записи пользователя)

===Рассинхронизация счетчика===
[[OATH]]-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимость синхронности значений счетчика событий, используемого генератором (клиентом) и сервером в процессе расчета и проверки одноразового пароля.
Как сказано выше инкремент счетчика генератора выполняется каждый раз, когда выполняется генерация одноразового пароля. В то же время инкремент счетчика на сервере выполняется только в случае успешной аутентификации. Исходя из этого можно выделить несколько наиболее вероятных причин ресинхронизации:
#Аутентификация не пройдена. Генератор инкрементировал свой счётчик, а сервер нет.
#Проблема связи. Генератор инкрементировал свой счётчик, а север не получил одноразовый пароль. В этом случае при невнятном сообщении об ошибке пользователь с высокой вероятностью выполнит повторную генерацию одноразового пароля.
#Элементарное баловство :)

===Ресинхронизация счетчика===

Ресинхронизация выполняется расчетом следующего HOTP-значения и сравнением с полученным от клиента (генератора). Это повторяется в переделах заданного окна ресинхронизации s. Дополнительно в процессе ресинхронизации сервер может запросить дополнительные значения одноразовых паролей (2 или 3). Это сделано для повышения безопасности, так как сравнения в этом случае выполняется для двух или трех пар, и все они должны пройти успешно.
Параметр s — определяет окно, в пределах которого сервер увеличивать счетчик в процессе ресинхронизации.

Это ограничение вводится по двум причинам:

#ограничить вероятность подбора одноразового значения (см ниже расчет вероятности)
# предотвратить бесконечный расчет в рамках одной проверки и как следствие отказ в обслуживании

==Математическая подоплека==

===Общее===
В основе генерации одноразовых паролей лежит HMAC-функция, на вход которой подается два значения: симметричный ключ и текущее состояние счетчика. Отсюда, кстати, и название алгоритма HOTP — HMAC-Based One-Time Password. В качестве основы HMAC взят алгоритм SHA-1 (RFC 3174), то есть речь идет о HMAC-SHA-1 (RFC 2104) с длиной результата 160 бит.

Так как конечный пользователь будет испытывать катастрофические затруднения при наборе одноразового пароля длиной 160 бит, алгоритм предусматривает обрезку оригинального результата (160 бит) до приемлемой длины: одноразовый пароль имеет формат цифрового значения с длиной не менее 6 символов (цифр).
Таким образом, функция генерации одноразового пароля по событию записывается следующим образом:

<center>HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))</center>

где:

К — симметричный ключ

С — текущее состояние счетчика

T — количество неверных аутентификаций, после которых сервер заблокирует учетную запись пользователя

s — параметр рассинхронизации, определяет максимальное расхождение между счетчиком сервера и генератора (клиента в [[OATH]]-терминологии), при котором одноразовый пароль будет принят.

Digit — количество цифр в значении одноразового пароля

Truncate — функция обрезки, позволяющая преобразовать 160-битное значение функции HMAC-SHA-1, в упомянутый выше юзер-френдли числовой формат (с длиной 6 или более символов)

===Как работает Truncate (обрезка)===

Результат HMAC-SHA-1 (RFC 2104)— 160 бит или строка, состоящая из 20 байт, на основе чего генерируется строка в 4 байта. Это происходит следующим образом:

20-байтная строка представляется как 20 блоков по 8 бит, 4 младших бита последней 20-ой 8-битной последовательности определяют смещение (понятно, что это значение находится в диапазоне от 0 до 15). Далее выполняется конкатенация (склеивание) 4 последовательностей, первая из которых является строковым предобразованием вычисленного смещения, а вторая — преобразованием от смещения увеличенного на единицу и т.д. последние 31 бита этой склейки и будут теми 4 байтами.

Далее 4 байта представляются как десятичное число, которое делится по модулю на 10^Digit. Результат и есть одноразовый пароль

==Аспекты безопасности==

===Надежность алгоритма===

Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack).
Легко понять, что вероятность прохождения аутентификации будет считаться по формуле:

<center>Sec = sT/10^Digit</center>

где:

Sec — рассчитываемая вероятность

s — окно допустимой расссинхронизации счетчиков на сервере и клиенте (генераторе)

T — количество попыток пройти аутентификации, при достижении которого учетная запись пользователя блокируется

Digit — количество цифр в одноразовом пароле.

Например, при 5 разрешенных попытках, окне допустимом окне рассинхронизации равном 30 и 6-цифровом одноразовом пароле, вероятность подобрать пароль составит и пройти аутентификацию составит: 0.015%

===Требования===

#Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым - некоторый дополнительный секрет, который добавляется к одноразовому паролю.
#Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае) должна блокироваться после оправленного числа неуспешных попыток аутентификации
#Необходимо использовать защищенный канал

Одноразовый пароль

2013-08-12T08:55:59Z

Korabelnikov: /* Синхронный комбинированные алгоритм (время и событие) */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны смешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия - "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использован только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») - пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерирован в любой момент времени (нет «интервала ожидания»)
#OTP может быть использован в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметра, а не один как это происходит в случае алгоритмов на базе времени или события.

Одноразовый пароль

2013-08-12T08:55:47Z

Korabelnikov: /* Синхронный комбинированные алгоритм (время и событие) */

Одноразовый пароль

2013-08-12T08:54:31Z

Korabelnikov: /* Синхронный алгоритм на базе события */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны смешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия - "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использован только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») - пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерирован в любой момент времени (нет «интервала ожидания»)
#OTP может быть использован в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события предпочтительно более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметре, а не один как это происходит в случае алгоритмов на базе времени или события

Одноразовый пароль

2013-08-09T14:05:02Z

Korabelnikov: /* Синхронный алгоритм на базе времени */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны смешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия - "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использован только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») - пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерировано в любой момент времени (нет «интервала ожидания»)
#OTP может быть использовано в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события предпочтительно более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметре, а не один как это происходит в случае алгоритмов на базе времени или события

Одноразовый пароль

2013-07-25T09:12:36Z

Korabelnikov: /* Асинхронные */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны смешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия - "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использовано только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») -- пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерировано в любой момент времени (нет «интервала ожидания»)
#OTP может быть использовано в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события предпочтительно более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметре, а не один как это происходит в случае алгоритмов на базе времени или события

Одноразовый пароль

2013-07-25T09:12:02Z

Korabelnikov: /* Смешанные алгоритмы */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны смешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия -- "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использовано только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») -- пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерировано в любой момент времени (нет «интервала ожидания»)
#OTP может быть использовано в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события предпочтительно более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметре, а не один как это происходит в случае алгоритмов на базе времени или события

Одноразовый пароль

2013-07-25T09:11:19Z

Korabelnikov: /* Алгоритмы на основе события */

==Основное==

OTP — one-time password, пароль, который может быть использован в процессе аутентификации только один раз.

Основная цель использования одноразовых паролей — предотвращение атак «запись-воспроизведение», которым подвержены простые статические пароли.

Одноразовый пароль — это результат некоторой математической функции (алгоритма), которая может быть реализована в виде портативного устройства (аппаратная реализация, генератор одноразовых паролей, OTP-генератор), программы для компьютера или мобильного телефона (программная реализация), в виде микропрограммы для [[EMV]]-чипа банковской карты (технологии CAP/DPA от MasterCard и Visa соответственно) или реализована в микрочипе, встроенным в пластик [[EMV]]-карточки (например, решения [http://powersecurity.ru/ru/solutions/nids/ NagraID]). Пользователю могут и вовсе не требоваться дополнительные аппаратные или программные реализации, например, одноразовый пароль может доставляться пользователю в виде SMS-сообщений или по email.

==Группы алгоритмов==

Существует две группы алгоритмов генерации одноразовых паролей:

#Синхронное
#Асинхронное

===Синхронные алгоритмы===

Название подсказывает, алгоритм генерации одноразового пароля предполагает, что некоторые параметры (на проверяющем сервере и клиентском устройстве, например OTP-генераторе) находятся в синхронном состоянии.

Существует 2 параметра генерации одноразовых паролей: время и событие.

====Алгоритмы на основе времени====
В качестве элемента, отвечающего за динамику, используется дискретное значение времени. Примером такого алгоритма является [[OATH]] [[TOTP]]

====Алгоритмы на основе события====
Каждый раз, когда пользователь инициирует генерацию OTP, происходит увеличение счетчика событий в генераторе. Значение этого счётчика и есть то значение (количество событий генерации), на основе которого рассчитывается одноразовый пароль. Примером такого алгоритма является [[OATH]] [[HOTP]]

====Смешанные алгоритмы====

Так как оба алгоритма (основанные и на времени, и на событии) имеют недостатки, были разработаны мешанные алгоритмы, использующие одновременно и дискретное состояние времени, и состояние счетчика событий.
[[OATH]] еще не разработал и не стандартизовал такой алгоритм, поэтому смешанные алгоритмы следует искать только среди проприетарных, например [http://www.vasco.com Vasco] и [http://www.actividentity.com ActivIdentity]

===Асинхронные===
Синоним названия -- "запрос-ответ" (от английского challenge-response). Здесь в качестве переменной, вместо состояния времени или счетчика событий, используется «запрос», получаемый с сервера.
Запрос вводится в генератор, пропускается через алгоритм, результатом которого является «ответ» — он и используется как одноразовый пароль. Примером асинхронного алгоритма генерации OTP является алгоритм [[OATH]] [[OCRA]]

==Сравнение синхронных алгоритмов==

=== Синхронный алгоритм на базе времени ===

#OTP использует время, а вернее его дискретное значение, а значит есть временной интервал, равный шагу, в течение которого OTP-значение не может поменяться (так как в течение этого интервала дискретное значение не меняется) — «интервал ожидания» (например, каждые 30 секунд)
#OTP имеет параметр «время жизни», в течение которого сервер будет принимать OTP (например, 2 минуты)
#Хорошая защита от фишинга, так как одноразовый пароль может быть использовано только в течение «времени жизни»
#Необходимо разрабатывать защиту от повторного использования, так как OTP на базе времени успешно пройдет повторную проверку.
#Невозможно сгенерировать новое OTP в рамках текущего временного интервала («интервала ожидания») -- пользователь должен ждать окончания текущего временного интервала.

Очевидны следующие ситуации:

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

=== Синхронный алгоритм на базе события ===

#OTP может быть сгенерировано в любой момент времени (нет «интервала ожидания»)
#OTP может быть использовано в любой момент времени после генерации (нет «времени жизни»)
#Подвержен фишинг-атакам, так как нет ограничения на использования в рамках «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

=== Синхронный комбинированные алгоритм (время и событие) ===

#OTP имеет параметр «время жизни» (например, 2 минуты)
#OTP может быть сгенерирован и использован в любой момент времени после предыдущей генерации (нет «интервала ожидания», так как вместе с дискретным значением времени используется и счетчик событий, который меняется каждый раз при генерации)
#Хорошая защита от фишинга, так как может быть использовано только в течение «времени жизни»
#Простая нативная защита от повторного использования, на базе счетчика событий

Как видно из вышесказанного, с точки зрения надежности комбинированный алгоритм на базе времени и события предпочтительно более предпочтителен. При этом стоит отметить, что при использовании 2х переменных (время и событие) процесс ручной синхронизации генератора одноразовых паролей будет сложнее, так как пользователю придется указывать два параметре, а не один как это происходит в случае алгоритмов на базе времени или события

OCRA

2013-07-25T06:29:41Z

Korabelnikov: /* DataInput */

==Основное==

OCRA (OATH Challenge-Response Algorithm, стандартизован как RFC 6287) это развитие алгоритма [[HOTP]]. В общих чертах – это алгоритм генерации одноразового значения на основании случайного значения (запроса), то есть вместо счетчика событий на вход подается случайное значение, полученное с сервера.
В дополнение аутентификации клиента здесь добавлены такие возможности как взаимная аутентификация, подпись транзакций

== Требования, предъявляемые к реализации==

# Алгоритм должен поддерживать аутентификацию на основе запрос-ответ (что собственно и является основной целью данного алгоритма)
# Алгоритм должен поддерживать подпись данных на основе симметричного ключа
# Алгоритм должен поддерживать аутентификацию сервера, для возможности подтвердить, что клиент взаимодействует с доверенным сервером
# Длина и формат запроса должны быть настраиваемыми
# Длина и формат ответа должны быть настраиваемыми
# Запрос может генерироваться с проверкой целостности, с вставкой контрольного бита. Это позволит убедиться в том, что запрос введен верно
# Каждый токен (генератор) программный или аппаратный должен иметь уникальный секрет (ключ), значение которого генерируется случайным образом или рассчитывается по специальным алгоритма генерации колючей.
# Алгоритм может поддерживать дополнительные атрибуты, такие как штамп времени или информация о сессии.

==Математика процесса==
Если описывать алгоритм, то можно использовать следующее представление:

OCRA = CryptoFunction(K, DataInput)

где,

К — общий секрет

DataInput — структура данных, названная выше случайным значением

CryptoFunction — функция расчета

=== DataInput===
DataInput = {OCRASuite | 00 | C | Q | P | S | T}

где,
00 – разделитель

С – беззнаковый 8-байтный счетчик, синхронизированный между обоими участниками (клиент и сервер). Опциональный параметр

Q – 128-байтный запрос, если он короче, то значение дополняется нулями

P – хэш-функция (поддерживается SHA-1 RFC 3174, SHA-256 и SHA-512) от [[PIN]]-кода, который известен обеим сторонам (клиент и сервер)

S – строка, длиной до 512 байт, описывающая параметры сессии

T – 8-байтное значение временных интервалов (секунд, минут, часов, дней – зависит от конкретной реализации), прошедших с 1 января 1 1970 (UT), используется для простановки штампа времени

При расчете значения, состояние счетчика (С) на стороне клиента всегда увеличивается на 1, а на стороне сервера только в случае успешного прохождения аутентификации (подтверждения транзакции)

=== CryptoFunction===
По умолчанию, в качестве функции используется HOTP-SHA1-6, то есть алгоритм [[HOTP]] на базе SHA1 c длиной значения 6 цифр.
Рассматривается семейство [[HOTP]]-функций, как расширение [[HOTP]]:
# HOTP-H-t , где варьируются H – алгоритм хэш-функции, t – длина значения, то есть обрезки
# HOTP-H-t, если t=0, то обрезка не выполняется и в качестве значения используется полное значение хэш-функции.
Рекомендуемые варианты:
# HOTP-SHA1-4
# HOTP-SHA1-6
# HOTP-SHA1-8
# HOTP-SHA256-6
# HOTP-SHA512-6

===OCRASuite===

Это текстовая строка, представленная в виде:
<Algorithm>:<CryptoFunction>:<DataInput>

OATH

2013-06-04T17:08:13Z

Korabelnikov:

'''OATH''' (Open AuTHentication, [http://www.openauthentication.org]) — международная инициативная группа, состоящая из разработчиков систем строгой аутентификации, основной целью которой являются стандартизация (разработка стандартов на уровне RFC) алгоритмов генерации одноразовых паролей ([[одноразовый пароль|OTP, one-time password]]) и разработка архитектуры решения. Основная идея — обеспечить полную совместимость компонентов решения по [[строгая аутентификация|строгой аутентификации]] разных производителей. Для формализации этой задачи разработана Программа OATH-Сертификации (OATH Certification Program [http://www.openauthentication.org/certification]).

В инициативную группу OATH входят такие компании, как Nexus(PortWise), [http://powersecurity.ru/ru/solutions/nids/ Nagra ID], ActivIdentity, Entrust, Gemalto, Lieberman Software, N-Crypt, Symantec, SanDisk, TotalTexto, VeriSign и другие.

Основные наработки:

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по событию (event-base) — [[HOTP]], описан в виде RFC 4226

*Синхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] по времени (time-base) — [[TOTP]], описан в виде RFC 6238

*Асинхронный алгоритм генерации [[одноразовый пароль|одноразовых паролей]] в режиме запрос-ответ (challenge-response) — [[OCRA]], описан в виде RFC 6287

*Стандарт конфигурационного файла генератора [[одноразовый пароль|одноразовых паролей]] (переносимый контейнер симметричного колюч) — PSKC (Portable Symmetric Key Container), описан в виде RFC 6030

Кроме того было разработано описание архитектуры в виде документа OATH Reference Architecture (текущая версия — вторая) [http://www.openauthentication.org/webfm_send/1]