На протяжении последних лет EDI сообщество демонстрирует постоянно растущий интерес к AS2. Чем же в действительности является AS2? Перед Вами третья статья из серии, посвященной изучению AS2 и значению AS2 применительно к EDI рынку.
Если требуется полная историческая и техническая информация, то предлагаю обратиться к Google c запросом: “AS2”. Данная серия посвящена практическим аспектам использования и не будет докучать избыточной детализацией. (См. AS2: Часть 1 – Что это? AS2: Часть 2 – Лучшие практики)
В соединиениях по протоколу AS2 сертификаты применяются как для шифрования, так и для подписи сообщений. Это и огромное приемущество AS2, и, одновременно, его недостаток. В данной статье я исследую причины этого, покажу как сертификаты работают и предложу пути улучшения работы. Не будем погружаться в технические детали, рассматривайте статью как руководство пользователя AS2 по сертификатам.
Основные понятия
Термены “сертификаты и “ключи” часто путают и применяют один вместо другого. В кратце, различия в следующем:
- В действительности ключи являются цепочкой байтов, применяемых в процессе шифрования/подписи. Ключи состоят из двух частей: публичный (открытый) ключ и частный (закрытый) ключ. Частные ключи держат в секрете и никогда не распространяют. Доступ к публичным ключам открыт. Так образуется уникальная частно/публичная пара, применеямая для шифрования/дешифрования и подписи/верификации.
- Серитификаты – это контейнеры, которые содержат ключи (X.509 – наиболее распространенный стандарт, определяющий форматы данных и процедуры распределения открытых ключей с помощью сертификатов). В сертификате содержится информация о том, как ключ может использоваться (например, шифрование, подпись, шифрование и подпись и т.д.) и до какой даты ключи остаются действительными. Публичные ключи всегда высылаются в сертификатах.
Для использования сертификата генерируется ключевая пара — частный/публичный ключи. Пользователь хранит частный ключ зашифрованным и закрытым паролем и никогда никому его не дает. В то время как, публичный ключ свободно распространяется среди партнеров. Применяя эту пару сертификатов/ключей, пользователь может быть уверен, что зашифрованные данные будут отркрыты только определенным получателем. Дополнительно, отправитель может подписать данные и получатель удостоверит отправителя и то, что данные не были изменены.
Способность шифровать и подписывать — это краеугольный камень AS2 и делает его великим. Практически каждый пакет AS2 позволяет посылать данные без подписи или шифрования, но, на протяжении всей своей жизни, я не могу понять, для чего они это делают. Также существует возможность использовать разные пары публичных/частных ключей для шифрования и подписи данных. К счастью, я не пересекался ни с одним человеком, кто бы делал это. Это добавляет ненужную сложность и удваивает работу по обслуживанию сертификатов.
Шифрование
Предположим, у нас есть два пользователя: Арон и Боб. Арон хочет зашифровать данные и отправить их Бобу. До того как это сделать, пользователь Боб обязан прислать Арону копию своего публичного сертификата. Затем Арон формирует данные, которые хочет отправить Бобу, и шифрует их с помощью публичного сертификата Боба. Когда Боб получит данные, он расшифрует их с помощью своего частного (закрытого) ключа..
Арон: Исходный документ + Публичный сертификат Боба = Зашифрованный документ
Боб: Зашифрованный документ + Частный ключ = Исходный документ
AS2 управляет этим процессом, помещая публичные сертификаты Ваших партнеров в специальное хранилище. В процессе отправки партнеру, AS2 программа извлекает соответствующий публичный сертификат и шифрует исходящие даные. Этот блок данных может быть расшифрован только при помощи частного ключа партнера. Если же данные оказываются в чужих руках, то расшифровать их будет очень сложно. Шифрование хотя и несовершенно, взлом шифра требует гигантской вычислительной мощности, однако степень защиты вполне достаточна для удовлетворения наших потребностей.
Подпись
Вернемся к нашим пользователям Арону и Бобу. Теперь Арон хочет подписать данные, чтобы Боб мог удостовериться, что данные отправлены именно Ароном и что они не изменены в процессе передачи. В этом процессе ключи примеяются в обратной последовательности. Изначально Боб должен иметь копию публичного сертификата Арона. Арон берет данные к отправке и выполняет алгоритм подписи, используя свой частный (закрытый) ключ. Таким образом, генерируется уникальная цифровая подпись (набор символов, известный как хэш), основавнная на данных и частном ключе. Эта подпись, наряду с данными, отправляется Бобу. Затем Боб обрабатывает данные и подпись алгоритмом, используя публичный ключ Арона. Если все подходит, то это подтверждает, что именно Арон отправил данные и что они не были изменены
Арон: Исходный документ + Частный ключ Арона = Цифровая подпись
Боб: Исходный документ + Цифровая подпись + Публичный ключ Арона = Подтверждено
Повторюсь, AS2 делает это для Вас, создавая цифровую подпись для Ваших данных и Вашего частного ключа и отправляет и оправляя ее всместе с зашифрованными данными. Для каждого набора данных формируется уникальная подпись, но она может быть верифицированна любым, у кого имеется Ваш публичный ключ. Поэтому мы употребляем термин “подпись”, а не “шифрование.
Собрав вместе Подпись и Шифрование получим:
Арон: Исходный документ + Частный ключ Арона = Цифровая подпись
Арон: Исходный документ + Публичный ключ Боба = Зашифрованный документ
Боб: Зашифрованный документ + Частный ключ Боба = Исходный документ
Боб: Исходный документ + Цифровая подпись + Публичный ключ Арона = Подверждено.
Органы сертификации/Удостоверяющие центры
Нам всем знакомы Органы сертификации – по посещениям защищенных веб-сайтов (особенно тех, у которых проблемы с сертификатами). Сертификаты на этих сайтах выполняют две функции:
- Сертификаты обеспечивают шифрование входящих/исходящих с сервера данных (SSL)
- Орган сертификаци подтверждает аутентичность владельца сайта (я не буду обсуждать насколько обоснованно это предположение… Оставлю тему для других..).
Тут мы имеем отличную от AS2 модель. Посещая защищенный веб-сайт, Вы не получаете публичный ключ владельца сайта, наоборт, Орган сертифкации обеспечивает доверие если Ваш компьютер уже имеет публичный ключ Органа сертификации в своем репозитории. Ваше доверие к сайту основано на доверии к Органу сетрификации (“цепочка” доверия).
В случае с AS2 нам не требуется Орган сертификации для удостоверения надежности другой стороны, т.к. мы уже получили публичный сертификат по другому каналу. Это означает, что получение публичного сертификата, завереного Органом сертификации, является тратой времени и денег.
Если деловой партнер присылает Вам подписанный сертификат, а вместе с ним цепочку сертификатов Органов сертификации, то будтьте готовы не обращать внимания на эти сертификаты и просто установите полученный публичный сертификат партнера как если бы он был “самоподписанный”.
Самоподписанные сертификаты
Вместо использования услуг Органов сертификации, практически каждый AS2 пакет позволяет генерировать и подписывать Ваш собственный сертификат. В процессе будут сгенерированы публичный и частный ключи, действительные заданное Вами время (о том, как определять этот срок, см. ниже). Частный ключ будет сохранен в защищенном месте, доступном для ПО AS2, а публичный сертификат будет помещен туда, откуда Вы сможете рассылать его копии своим партнерам.
Одно замечание по поводу самоподписанных сертификатов. Вы должны быть уверены, что используете уникальное последовательное число каждый раз, когда генерируете новый сертификат. Некоторые пакеты AS2 делают это автоматически, другие каждый раз требуют от Вас ввода уникального числа. Если Вам требуется ввести уникальное число, не усложняйте и просто используйте текущую дату, например, 20130803.
Обмен сертификатами
Публичные сертификаты в основном хранятся в файлах, оканчивающихся на .cer, .crt или .der. В любом случае, они могут быть в двоичном или PEM формате. format. Лично я предпочитаю PEM, т.к. он декодирован BASE64 и даже может быть скопирован и вставлен в текст сообщения электронной почты. Вот пример нашего публичного сертификата в формате PEM:
——BEGIN CERTIFICATE—— MIIBtjCCAR+gAwIBAgIBAzANBgkqhkiG9w0BAQUFADAhMR8wHQYDVQQDExZFQ0dyaWQgQVMyIENl cnRpZmljYXRlMB4XDTA3MTAwMTIxMTcxNloXDTE3MTAwMTIxMTcxNlowITEfMB0GA1UEAxMWRUNH cmlkIEFTMiBDZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAziLTH4urrO8s LBCIz6vKWunuIeEpRuVQz6B+7UYzmhckB18VDjYBI5Bp4IFIRJxwsqJx8hoLNJivX26T9zDtcmO+ X58FeyIyea1ecp/cwi3ebdWpiLaxQPCV3nLQx/3mas8LHWSDlg5NT3VgPzFJHQoY1ukdPDVgnApn n877ygMCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDOGQc4UfQj0p7AEUAd+8Ue+/hRomyI4/RvaRv9 fjw2a1BhZfmzrUXTReIKzuhIKfXoX22YyTP5MVTWzKeIh2qIc/488rAh5yOsoHsHRVGoTDibLWvN /wiMRYhw6TY6Vnz+3IyXyNtktspAg7wprno1pkmAw63sONAR+996og43UQ== ——END CERTIFICATE——
Вы можете Вырезать / Вставить этот пример при помощи текстового редактора (например, Блокнот), сохранить файл с расширением .cer, затем открыть его и ознакомиться со всеми внутренними значениями.
Вне зависимости от формата, многоие почтовые программы будут блокировать вложенные файлы с расширением .cer, .crt и .der (очень опасные файлы…). Можно просто добавить .txt к концу файла (например, ecgrid.cer.txt), чтобы отправить его как вложение. Вы можете также сжать его в ZIP файл. Я предпочитаю архивировать всю информацию по AS2, наши сертификаты и контактные данные в один файл. Таким образом партнеры хранят нашу информацию в одном месте.
Имена файлов…Пожалуйста, не называйте Ваши файлы as2.cer, myas2certificate.der или подобным образом (да, я постоянно сталкиваюсь с этим). Присваивайте значимые имена. Ваши партнеры наверняка работают не только с Вами, и Ваши данные должны быть уникальными и удобными. Когда Вы высылаете замену сертификату, не отправляйте файл с таким же именем, как у заменяемого сертификата. Я предлагаю следующий формат:
<as2id>.<дата начала>-<дата окончания>.cer Например: ECGRID.20071001-20171001.cer
Устаревшие сертификаты
До сих пор все было хорошо, но сейчас мы подошли к недостаткам использования сертификатов в AS2. Какой срок действия назначить сертификату и как это повлияет на моих партнеров?
Это одина из наименее продуманных частей пакетов ПО AS2. Так как каждый сеанс связи требует точного соответсвия частных и публичных ключей, то если один пользователь AS2 меняет свой частный ключ (прим редакции: а вместе с ним и публичный ключ, то есть ключевую пару), то все партнеры должны одновременно поменять в своих записях публичные сертификаты этого пользователя. Мы все это знаем, что такое срочные обновления, выпадающие на неопределенное время и день недели. Уф. Этого не должно быть, но так устроено все, почти все ПО AS2.
Только представьте, сколько людей в Wal-Mart ежедневно обновляют сертификаты своих партнеров! Интересно отметить, что Wal-Mart решил проблему мгновенной замены своего собственного сертификата путем установки уникального частного ключа на своей стороне для каждого партнера (прим. редакции: сколько партнеров, столько и ключевых пар и сертификатов к ним выпускает и поддерживает Wal-Mart). Это позволяет избежать одновременного массового обновления сертификатов, но существенно увеличивает объем работы для самого Wal-Mart. Грубый силовой метод решения большой проблемы.
Я долго и много обдумывал определение срока действия сертификата. Одни говорят, что нельзя устанавливать его слишком большим, т.к. сертификат может быть скомпрометирован. Но чем чаще приходится менять сертификаты, тем в большую проблему это выливается для Вас и Ваших партнеров. Я пришел к выводу, что нужно выдавать сертификат на очень большой срок (десять и более лет). Если он будет скомпрометирован, то Вы можете просто перестать его использовать и заменить на новый.
Я должен признать, что мы выпустили свой первый сертификат сроком на один год. Живи и учись. Я убежден, что тысячи компаний, трафик которых проходит через наш AS2 хаб, счастливы, что им не приходится регулярно менять сертификаты. Wal-Mart сознательно не позволяет принять сертификаты, действительные более 5 лет, поэтому для них у нас есть специальный сертификат.
Когда подходит время менять сертификаты, оповестите своего партнера о дате смены как минимум за месяц и меняйте сертификат за 2-4 недели до окончания его срока действия. Пожалуйста, не назначайте смену на субботу в 3 утра. Также, когда рассылаете уведомления об обновлении своего сертификата, учитывайте часовые пояса. Я получаю множество запросов на смену в “стандартной” часовой зоне, когда в действительности уже давно не день. Я предлагаю дополнительно указывать эквивалент времени UTC, что позволит избежать двусмысленности.
Если Вы добавляете партнера накануне смены сертификата, то ему не удастся избежать этой процедуры. Сообщите ему сразу, что Вы планируете вскоре сменить сертификаты. Это будет просто вежливо..
Лично я считаю, что обмен и обновление сертификатов – это крупнейший недостаток AS2. В Loren Data, мы сосредоточены на этом вопросе, как на ключевом моменте, ограничивающем более широкое использование AS2. Пакеты ПО AS2 должны знать, как обмениваться и публичными сертификатами автоматически, в защищенном и надежном режиме.
Если все правильно установить и настроить, то можно будет менять сертификаты еженедельно или ежедневно, не задействуя своих партнеров! Однако сейчас, каждая замена сертификата – это головная боль, поэтому всегда думайте о своих партнерах, когда приходит время менять сертификаты.
Примечание: Сохраняйте свои устаревшие частные ключи и публичные сертификаты партнеров. Они Вам потребуются, если по какой-то причине возникнет необходимость переподтвердить или расшифровать старое сообщение. (прим. редакции: без этого может оказаться невозможен доступ к архиву документов, сформированных несколько лет назад)
Сертификаты для SSL и HTTP
Поскольку AS2 использует HTTP протокол, то есть возможность пользоваться протоколом HTTPS (SSL) взамен простого открытого HTTP. Таким образом будет зашифрован весь сеанс связи между AS2 системами. Честно говоря, это избыточно и требует дополнительной траты ресурсов. Данные уже подписаны и зашифрованы. Никто из прослушивающих канал не сможет ничего с ними сделать. Добавление SSL в Ваши AS2 соединения только вынудит систему работать тяжелее, шифруя уже зашифрованные данные. Да, конечно, это позволит зашифровать заголовки сообщений. Но зачем?
Дополнительно, использование SSL поверх AS2 также приводит к необхоодимости обслуживать еще один сертификат. И, если Вам абсолютно необходимо использовать SSL сертификат, возьмите сертификат наиболее известного Органа сертификации. Если Вы этого не сделаете, то партнерам придется импортировать Ваш сертификат во всевозможные труднодоступные места своих систем, чтобы использовать Ваше SSL соединение.
Другая ненужная и, к счастью, редко востребованнная возможность AS2 – использование HTTP клиент-сертификатов. Это позволяет AS2 клиенту проходить аутентификацию на сервере AS2 на уровне HTTP. Опять же, абсолютно ненужную, так как все проверки, которые могут потребоваться, содержатся в самом протоколе AS2.
Подведем итог вышесказанному:
- Создавайте сертификаты действующие пять, десять или более лет.
- Сохраняйте публичные сертификаты в формате PEM, присваивая значимые имена файлов. Отправляя по электронной почте во вложении, архивируйте сертификат, AS2 информацию и контактные данные в один файл.
- Планируйте замену сертификата минимум за 2 недели до истечения срока действия сертификата, в норамальные рабочие часы, когда трафик минимальный, включайте в сообщение UTC время и сообщайте о планируемой замене как минимум за 4 недели.
- Сохраняйте все свои старые частные ключи и публичные сертификаты (свои и партнеров).
- Не тратьте время и деньги на Органы сертификации.
- Не используйте SSL или клиентские сертификаты.
- Наслаждайтесь дешевыми, защищенными, аутентифицированными EDI соединениями!
Следующий раз, после того как мы исследовали основы AS2, я планирую поделиться с Вами, над чем мы работаем за сценой, что бы перевести AS2 на следующий уровень…
Тодд Гулд (Todd Gould, President Loren Data Corp)