Сертификат авторизации

В компьютерной безопасности или сертификат атрибута сертификат авторизации ( AC ) представляет собой цифровой документ , содержащий атрибуты, связанные с держателем эмитентом. ^{[ 1 ]} Когда связанные атрибуты в основном используются с целью авторизации , AC называется сертификатом авторизации . AC стандартизирован в X.509 . RFC 5755 дополнительно определяет использование для целей авторизации в Интернете.

Сертификат авторизации работает совместно с сертификатом открытого ключа (PKC). В то время как PKC выдается центром сертификации (CA) и используется в качестве доказательства личности его владельца, как паспорт , сертификат авторизации выдается центром сертификации (AA) и используется для характеристики или предоставления прав его владельцу, как сертификат виза . Поскольку идентификационная информация редко меняется и имеет длительный срок действия, в то время как атрибутивная информация часто меняется или имеет короткий срок действия, необходимы отдельные сертификаты с разными требованиями безопасности, сроками действия и эмитентами. ^{[ 2 ]}

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

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

Проверка AC требует присутствия PKC, который называется держателем AC в AC.

Как и в случае с 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.

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

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

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

Версия : версия сертификата.

Держатель : владелец сертификата.

Эмитент : эмитент сертификата.

Алгоритм подписи : алгоритм, которым подписывается сертификат.

Серийный номер : уникальный номер выпуска, присвоенный эмитентом.

Срок действия : срок действия сертификата.

Атрибуты : атрибуты, связанные с держателем сертификата.

Значение подписи : подпись эмитента над всеми данными, указанными выше.

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

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

См. также

Ссылки

^ Р. Ширей (август 2007 г.). Глоссарий по интернет-безопасности, версия 2 . Сетевая рабочая группа. дои : 10.17487/RFC4949 . РФК 4949 . Информационный.
^ Фаррелл, С.; Хаусли, Р. «Профиль или авторизация сертификата атрибута Интернета». РФК 3281. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

Внешние ссылки

Документация по сертификату SPKI/SDSI

[rfc4949-1] Р. Ширей (август 2007 г.). Глоссарий по интернет-безопасности, версия 2 . Сетевая рабочая группа. дои : 10.17487/RFC4949 . РФК 4949 . Информационный.

[2] Фаррелл, С.; Хаусли, Р. «Профиль или авторизация сертификата атрибута Интернета». РФК 3281. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[ 1 ]

[ 2 ]