Об XML-подписях

Adobe AIR 1.5 и более поздних версий

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

XML-подпись может применяться к любому типу цифровых данных (в двоичном или XML-формате). XML-подписи обычно используются в следующих целях:

  • для проверки, не изменялись ли внешние или загруженные ресурсы;

  • для проверки сообщений, полученных из внешних источников;

  • для проверки лицензий на приложение или связанных с подпиской прав.

Поддерживаемый синтаксис XML-подписи

Adobe AIR поддерживает следующие элементы из рекомендаций W3C для синтаксиса и порядка обработки XML-подписей:

  • Все базовые элементы синтаксиса подписей (раздел 4 в документе рекомендаций W3C), за исключением элемента KeyInfo, поддерживаемого не полностью

  • Элемент KeyInfo должен содержать только элемент X509Data

  • Элемент X509Data должен содержать только элемент X509Certificate

  • Метод создания дайджеста SHA256

  • Алгоритм подписания RSA-SHA1 (PKCS1)

  • Преобразование и метод канонизации «Канонический XML без комментариев»

  • Преобразование вложенной подписи

  • метки времени

В следующем документе проиллюстрирован пример стандартной XML-подписи (большая часть криптографических данных была удалена для упрощения этого примера).

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
    <SignedInfo> 
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 
        <Reference URI="URI_to_signed_data"> 
            <Transforms> 
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            </Transforms> 
            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 
            <DigestValue>uoo...vY=</DigestValue> 
        </Reference> 
    </SignedInfo> 
    <SignatureValue>Ked...w==</SignatureValue> 
    <KeyInfo> 
        <X509Data> 
            <X509Certificate>i7d...w==</X509Certificate> 
        </X509Data> 
    </KeyInfo> 
</Signature>

Ключевыми для подписи являются следующие элементы:

  • SignedInfo — Содержит ссылки на подписанные данные и расчетные значения дайджестов на момент подписания. Подписанные данные сами могут быть включены в тот же документ, что и XML-подпись, а также могут находиться вне его.

  • SignatureValue — Содержит дайджест элемента SignedInfo, зашифрованный закрытым ключом подписывающей стороны.

  • KeyInfo — Содержит подписывающий сертификат, а также любые дополнительные сертификаты, необходимые для установления цепи доверия. Обратите внимание, что, хотя элемент KeyInfo технически не обязателен, AIR не сможет проверить достоверность подписи при его отсутствии.

Существует три основных типа XML-подписей:

  • Вложенные — подпись вставляется в XML-данные, которые она подписывает.

  • Обертывающие — подписанные XML-данные содержатся в элементе-объекте внутри элемента подписи.

  • Отдельные — подписанные данные являются внешними по отношению к XML-подписи. Подписанные данные могут содержаться во внешнем файле. В качестве альтернативы, они также могут находиться в том же XML-документе, что и подпись, но не являются дочерними или родительскими элементами относительно элемента подписи.

XML-подписи используют идентификаторы URI для ссылки на подписанные данные. Подписывающее и проверяющее подпись приложения должны использовать одинаковые принципы разрешения этих идентификаторов URI. При использовании класса XMLSignatureValidator необходимо реализовать интерфейс IURIDereferencer. Этот интерфейс отвечает за разрешение идентификатора URI и возвращение подписанных данных в виде объекта ByteArray. Для возвращаемого объекта ByteArray вычисляется дайджест с помощью того же алгоритма. которым создавался дайджест в подписи.

Сертификаты и доверенное отношение

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

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

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

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

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

Истечение срока действия сертификатов и их отзыв

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

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