Атрибутные сертификаты: принципы и применение в компьютерной безопасности.

Введение

В области компьютерной безопасности атрибутный сертификат, или сертификат авторизации (AC), – это цифровой документ, содержащий атрибуты, связанные с владельцем издателем. Если связанные атрибуты используются главным образом для целей авторизации, AC называется сертификатом авторизации. AC стандартизован в X.509. RFC 5755 дополнительно определяет использование для целей авторизации в Интернете. Сертификат авторизации функционирует совместно с сертификатом открытого ключа (PKC). В то время как PKC выдается центром сертификации (CA) и используется в качестве доказательства личности его владельца, подобно паспорту, сертификат авторизации выдается органом, выдающим атрибуты (AA), и используется для характеристики или наделения прав владельца, подобно визе. Поскольку информация об идентификации редко меняется и имеет длительный срок действия, а информация об атрибутах часто меняется или имеет короткий срок действия, необходимы отдельные сертификаты с различными требованиями к безопасности, сроками действия и издателями.

Сравнение сертификатов атрибутов и открытых ключей

AC напоминает PKC, но не содержит открытого ключа, поскольку верификатор AC находится под контролем издателя AC и, следовательно, доверяет издателю напрямую, имея предварительно установленный открытый ключ издателя. Это означает, что как только личный ключ издателя AC будет скомпрометирован, издатель должен сгенерировать новую пару ключей и заменить старый открытый ключ во всех верификаторах под своим контролем на новый. Для проверки AC требуется наличие PKC, который в AC называется владельцем PKC. Как и в случае с PKC, AC может быть объединен в цепочку для делегирования полномочий. Например, сертификат авторизации, выданный для Алисы, разрешает ей использовать определенную услугу. Алиса может делегировать это право своему помощнику Бобу, выпустив AC для PKC Боба. Когда Боб хочет использовать услугу, он предъявляет свой PKC и цепочку AC, начиная с его собственного AC, выданного Алисой, а затем AC Алисы, выданного издателем, которому доверяет служба. Таким образом, служба может проверить, что Алиса делегировала свои права Бобу и что Алиса была авторизована использовать услугу издателем, контролирующим службу. Однако RFC 3281 не рекомендует использовать цепочки AC из-за сложности администрирования и обработки цепочки, и использование AC в Интернете ограничено.

Использование

Чтобы использовать услугу или ресурс, контролируемый эмитентом AC, пользователь предъявляет как PKC, так и AC части услуги или ресурса, функционирующей как верификатор AC. Верификатор сначала проверяет личность пользователя, используя PKC, например, попросив пользователя расшифровать сообщение, зашифрованное его публичным ключом в PKC. Если аутентификация прошла успешно, верификатор использует предварительно установленный открытый ключ эмитента AC для проверки действительности представленного AC. Если AC действителен, верификатор проверяет, соответствует ли PKC, указанный в AC, представленному PKC. Если соответствие установлено, верификатор проверяет срок действия AC. Если AC все еще действителен, верификатор может выполнить дополнительные проверки, прежде чем предоставить пользователю определенный уровень обслуживания или использования ресурсов в соответствии с атрибутами, содержащимися в AC. Например, разработчик программного обеспечения, у которого уже есть PKC, хочет развернуть свое программное обеспечение на вычислительном устройстве, использующем DRM, например, iPad, где программное обеспечение может быть запущено только после одобрения производителем устройства. Разработчик программного обеспечения подписывает программное обеспечение своим приватным ключом PKC и отправляет подписанное программное обеспечение производителю устройства для утверждения. После аутентификации разработчика с использованием PKC и проверки программного обеспечения, производитель может принять решение о выдаче AC, предоставляющего программному обеспечению базовую возможность установки и выполнения, а также дополнительную возможность использования Wi-Fi устройства в соответствии с принципом наименьших привилегий. В этом примере AC относится не к PKC разработчика как к владельцу, а к программному обеспечению, например, путем хранения подписи разработчика программного обеспечения в поле владельца AC. Когда программное обеспечение помещается в вычислительное устройство, устройство проверяет целостность программного обеспечения с использованием PKC разработчика, прежде чем проверять действительность AC и предоставлять программному обеспечению доступ к функциональным возможностям устройства. Пользователю также может потребоваться получить несколько AC от разных эмитентов для использования определенной услуги. Например, компания выдает одному из своих сотрудников корпоративный AC, определяющий инженерный отдел как рабочую область. Однако для доступа к инженерным данным сотруднику также требуется AC, подтверждающий разрешение на доступ, от руководителя инженерного отдела. В этом примере ресурс инженерных данных должен быть предварительно оснащен открытыми ключами эмитентов как корпоративного, так и AC инженерного отдела.

To use a service or a resource that the issuer of an AC controls, a user presents both the PKC and the AC to a part of the service or resource that functions as an AC verifier. The verifier will first check the identity of the user using the PKC, for example, by asking the user to decrypt a message encrypted by the user's public key in the PKC. If the authentication is successful, the verifier will use the preinstalled public key of the AC issuer to check the validity of the presented AC. If the AC is valid, the verifier will check whether or not the PKC specified in the AC matches the presented PKC. If it matches, the verifier will check the validity period of the AC. If the AC is still valid, the verifier can perform additional checks before offering the user a particular level of service or resource usage in accordance to the attributes contained in the AC. For example, a software developer that already has a PKC wants to deploy its software in a computing device employing DRM like iPad where software can only be run in the device after the software has been approved by the device manufacturer. The software developer signs the software with the private key of the PKC and sends the signed software to the device manufacturer for approval. After authenticating the developer using the PKC and reviewing the software, the manufacturer may decide to issue an AC granting the software the basic capability to install itself and be executed as well as an additional capability to use the Wi Fi device following the principle of least privilege. In this example, the AC does not refer to the PKC of the developer as the holder but to the software, for example, by storing the developer's signature of the software in the holder field of the AC. When the software is put into the computing device, the device will verify the integrity of the software using the developer's PKC before checking the validity of the AC and granting the software access to the device functionalities. A user may also need to obtain several ACs from different issuers to use a particular service. For example, a company gives one of its employees a company wide AC that specifies engineering department as the work area. To access engineering data, however, the employee also needs a security clearance AC from the head of the engineering department. In this example, the resource of engineering data needs to be preinstalled with the public keys of both the company wide and the engineering department AC issuers.

Содержание сертификата типового атрибута

Версия: версия сертификата. Владелец: владелец сертификата. Эмитент: издатель сертификата. Алгоритм подписи: алгоритм, используемый для подписи сертификата. Серийный номер: уникальный номер, присвоенный эмитентом при выдаче. Срок действия: период действия сертификата. Атрибуты: атрибуты, связанные с владельцем сертификата. Значение подписи: подпись эмитента от всех вышеуказанных данных.

Преимущества

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