PyDERASN: как написах библиотеката ASN.1 с slots and blobs

ASN.1 това е стандарт (ISO, ITU-T, ГОСТ) за език, описващ структурирана информация, както и правила за кодиране на тази информация. За мен като програмист, това е просто още един формат за серийно предаване и представяне на данни, наравно с JSON, XML, XDR и други. Той е широко разпространен в ежедневието ни и много хора се сблъскват с него: в мобилната и телефонна комуникация (UMTS, LTE, WiMAX, SS7, H.323), в мрежовите протоколи (LDAP, SNMP, Kerberos), във всичко, свързано с криптографията (X.509, CMS, PKCS стандарти), в банковите карти и биометричните паспорти, и много други места.

В тази статия ще разгледаме PyDERASN: библиотека Python за ASN.1, активно използвана в проекти, свързани с криптографията в Атласа.

Всъщност, не си струва да се препоръчва ASN.1 за криптографски задачи: ASN.1 и неговите кодеци са сложни. Това означава, че кодът няма да е прост, а това е винаги допълнителен вектор за атака. Достатъчно е да погледнете списъка на уязвимости в библиотеките ASN.1. Брус Шнайер в своята Cryptography engineering също не препоръчва използването на този стандарт поради неговата сложност: «The best-known TLV encoding is ASN.1, but it is incredibly complex and we shy away from it». Но за съжаление, днес имаме инфраструктури на публични ключове в които активно се използват сертификати X.509, CRL, OCSP, TSP, протоколи CMP, CMC, съобщения CMS, и куп стандарти PKCS. Затова трябва да умеете да работите с ASN.1, ако се занимавате с нещо, свързано с криптографията.

ASN.1 може да бъде кодирано по множество начини/кодеци:

• BER (Basic Encoding Rules)
• CER (Canonical Encoding Rules)
• DER (Distinguished Encoding Rules)
• GSER (Generic String Encoding Rules)
• JER (JSON Encoding Rules)
• LWER (Light Weight Encoding Rules)
• OER (Octet Encoding Rules)
• PER (Packed Encoding Rules)
• SER (Signalling specific Encoding Rules)
• XER (XML Encoding Rules)

и редица други. Но в криптографските задачи на практика се използват два: BER и DER. Дори в подписаните XML документи (XMLDSig, XAdES) все пак ще има Base64-кодирани ASN.1 DER обекти, както и в JSON ориентирания протокол ACME от Let’s Encrypt. По-добре е да се запознаете с всички тези кодеци и принципи за кодиране на BER/CER/DER в статии и книги: ASN.1 на прост език, ASN.1 — Общуване между хетерогенни системи от Оливие Дюбисон, ASN.1 Complete от проф. Джон Лармаут.

BER е бинарен байт-ориентиран (например PER, популярен в мобилната комуникация — битово ориентиран) TLV формат. Всеки елемент се кодира под формата на: етикет (Tag), идентифициращ типa на кодируемия елемент (цяло число, низ, дата и т.н.), дължина (Length) на съдържанието и самото съдържание (Value). BER по избор позволява да не се посочва стойност на дължината, задавайки специална стойност за неопределена дължина и завършвайки съобщението с етикет End-Of-Octets. Освен кодиране на дължината, в BER има много вариативност в начина на кодиране на типовете данни, като например:

• INTEGER, OBJECT IDENTIFIER, BIT STRING и дължината на елемента могат да бъдат ненормализирани (не кодирани в минимална форма);
• BOOLEAN е вярно при всяко ненулево съдържание;
• BIT STRING може да съдържа "излишни" нулеви битове;
• BIT STRING, OCTET STRING и всички техни производни низови типове, включително дата/време, могат да бъдат разделени на парчета (chunk) с променлива дължина, чиято дължина по време на (де)кодиране не е известна предварително;
• UTCTime/GeneralizedTime могат да имат различни начини за задаване на отклонение на времевата зона и "излишни" нулеви дроби от секундата;
• DEFAULT стойности SEQUENCE могат да бъдат кодирани, а могат и да не бъдат;
• Именованите стойности на последните битове в BIT STRING могат да не бъдат кодирани по желание;
• SEQUENCE (OF)/SET (OF) могат да имат произволен ред на елементите.

Поради всичко написано по-горе, кодиране на данни така, че да бъдат идентични на оригиналната форма — не винаги е възможно. Затова е създадено подмножество от правила: DER — строги регламенти, които определят единствения допустим начин на кодиране, което е критично за криптографски задачи, където, например, промяна на един бит ще направи подписа или контролната сума невалидна. DER има съществен недостатък: дължините на всички елементи трябва да са известни предварително по време на кодиране, което не позволява потоково сериализиране на данни. Кодекът CER е лишен от този недостатък, аналогично гарантирайки недвусмислено представяне на данни. За съжаление (или за щастие, че нямаме още по-сложни декодери?), той не стана популярен. Следователно, на практика ние срещаме "смешано" използване на BER и DER кодирани данни. Тъй като и CER, и DER са подмножество на BER, всеки BER декодер може да обработва и тях.

Проблеми с pyasn1

На работата пишем много програми на Python, свързани с криптография. Преди няколко години, изборът на свободни библиотеки беше почти незабележим: или много нискоуровневи библиотеки, които само позволяват кодиране/декодиране, например за цяло число и заглавие на структура, или библиотека pyasn1. Живеехме с нея няколко години и в началото бяхме много доволни, тъй като позволяваше работа с ASN.1 структури като с високопрофилни обекти: например декодираният обект на X.509 сертификата позволява достъп до полетата му чрез интерфейс с речник: cert[«tbsCertificate»][«serialNumber»] ще покаже серийния номер на този сертификат. По сходен начин, можем да „сглобяваме“ сложни обекти, работейки с тях като със списъци или речници, а след това просто да извикаме функцията pyasn1.codec.der.encoder.encode и да получим сериализираното представление на документа.

Въпреки това, бяха открити недостатъци, проблеми и ограничения. В pyasn1 имаше и, за съжаление, все още съществуват грешки: към момента на написването на статията, в pyasn1 един от основните типове — GeneralizedTime, неправилно декодира и кодира.

В нашите проекти, за икономия на място, често съхраняваме само пътя до файла, изместването и дължината в байтове на обекта, на който искаме да се позовем. Например, произволно подписан файл със сигурност ще е в структурата CMS SignedData ASN.1:

  0     [1,3,1018]  ContentInfo SEQUENCE
  4     [1,1,   9]   . contentType: ContentType OBJECT IDENTIFIER 1.2.840.113549.1.7.2 (id_signedData)
 19-4   [0,0,1003]   . content: [0] EXPLICIT [UNIV 16] ANY
 19     [1,3, 999]   . . DEFINED BY id_signedData: SignedData SEQUENCE
 23     [1,1,   1]   . . . version: CMSVersion INTEGER v3 (03)
 26     [1,1,  19]   . . . digestAlgorithms: DigestAlgorithmIdentifiers SET OF
                           [...]
 47     [1,3, 769]   . . . encapContentInfo: EncapsulatedContentInfo SEQUENCE
 51     [1,1,   8]   . . . . eContentType: ContentType OBJECT IDENTIFIER 1.3.6.1.5.5.7.12.2 (id_cct_PKIData)
 65-4   [1,3, 751]   . . . . eContent: [0] EXPLICIT OCTET STRING 751 bytes OPTIONAL

                 ТУТ СОДЕРЖИМОЕ ПОДПИСЫВАЕМОГО ФАЙЛА РАЗМЕРОМ 751 байт

820     [1,2, 199]   . . . signerInfos: SignerInfos SET OF
823     [1,2, 196]   . . . . 0: SignerInfo SEQUENCE
826     [1,1,   1]   . . . . . version: CMSVersion INTEGER v3 (03)
829     [0,0,  22]   . . . . . sid: SignerIdentifier CHOICE subjectKeyIdentifier
                               [...]
956     [1,1,  64]   . . . . . signature: SignatureValue OCTET STRING 64 байта
                     . . . . . . C1:B3:88:BA:F8:92:1C:E6:3E:41:9B:E0:D3:E9:AF:D8
                     . . . . . . 47:4A:8A:9D:94:5D:56:6B:F0:C1:20:38:D2:72:22:12
                     . . . . . . 9F:76:46:F6:51:5F:9A:8D:BF:D7:A6:9B:FD:C5:DA:D2
                     . . . . . . F3:6B:00:14:A4:9D:D7:B5:E1:A6:86:44:86:A7:E8:C9

и ние можем да извлечем оригиналния подписан файл с отместване 65 байта, дължина 751 байта. pyasn1 не съхранява тази информация в декодираните си обекти. Беше написана т.нар. TLVSeeker — малка библиотека, позволяваща декодиране на тагове и дължини на обекти, в интерфейса на която даваме команди „премини към следващия таг“, „влез в таг“ (влизаме в SEQUENCE обект), „премини към следващия таг“, „съобщи за своя offset и дължина на обекта, където се намираме“. Това беше „ръчно“ обход на ASN.1 DER-сериализирани данни. Но по този начин не можеше да се работи с BER-сериализирани данни, тъй като, например, байтовата строка OCTET STRING можеше да бъде кодирана в различни chunk-ове.

Друг недостатък за нашите цели на pyasn1 — невъзможността да се определи от декодираните обекти, било ли е зададеното поле в SEQUENCE или не. Например, ако структурата съдържа поле Field SEQUENCE OF Smth OPTIONAL, то можеше напълно да липсва в получените данни (OPTIONAL), но можеше и да присъства, но да е с нулева дължина (празен списък). В общия случай това не можеше да бъде установено. А това е необходимо за строгата проверка на валидността на получените данни. Представете си, че някой удостоверяващ център е издал сертификат с „не съвсем“ валидни от гледна точка на ASN.1-схемата данни! Например удостоверяващият център „TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı“ в своя коренен сертификат излезе извън допустимите RFC 5280 граници на дължината на компонента subject — невъзможно е честно да се декодира по схемата. DER кодек изисква, за да не се кодирай поле, чиято стойност е равна на DEFAULT-ната, при предаване — в живота срещаме такива документи и първата версия PyDERASN дори осъзнато допускаше такова невалидно (от гледна точка на DER) поведение заради обратна съвместимост.

Друго ограничение е, че не е лесно да се разбере в какъв формат (BER/DER) е кодирал конкретен обект в структурата. Например, стандартът CMS казва, че съобщението се кодира в BER, но полето signedAttrs, върху което се формира криптографската подпись, трябва да е в DER. Ако декодираме с DER, ще се сблъскаме с обработката на самата CMS, а ако декодираме с BER, няма да разберем в какъв формат е бил signedAttrs. В крайна сметка, ще трябва да използваме TLVSeeker (аналогът на който не съществува в pyasn1), за да намерим местоположението на всяко от полетата signedAttrs и да го декодираме поотделно от сериализираното представяне с DER.

За нас беше изключително желателна възможността за автоматична обработка на полета DEFINED BY, които се срещат много често. След декодирането на ASN.1 структура, може да останат множество ANY полета, които трябва да бъдат обработени по следната схема, избрана на базата на OBJECT IDENTIFIER, зададено в полето на структурата. В Python кода това означава написване на if и последващо извикване на декодера за ANY полето.

Появата на PyDERASN

В Атласа редовно, когато открием някакви проблеми или доработваме използваните свободни програми, изпращаме пачове нагоре. В pyasn1 няколко пъти сме изпращали доработки, но кодът на pyasn1 не е най-лесният за разбиране и понякога в него се случват несъвместими промени в API, които ни засегнат. Освен това сме свикнали да пишем тестове с генеративно тестване, което не беше налично в pyasn1.

В един прекрасен ден реших, че е време да спра да търпя и да опитам да напиша собствена библиотека с __slot__-ове, offset-ове и блобове, които да се визуализират прекрасно! Просто да създам ASN.1 кодек не би било достатъчно - трябваше да пренеса всичките ни взаимозависими проекти на нея, а това са стотици хиляди редове код, в които има много работа с ASN.1 структури. Тоест, едно от изискванията беше: лесно преносимост на текущия pyasn1 код. Изразходвайки цялата си отпуска, написах тази библиотека, и пренесох всички проекти на нея. Понеже те имат практически 100% покритие с тестове, това означаваше и пълна функционалност на библиотеката.

PyDERASN, аналогично, има практически 100% покритие с тестове. Използва се генеративно тестване с чудесната библиотека hypothesis. Провеждаше се и fuzzing py-afl-ем на 32-ядрени машини. Независимо от факта, че почти нямаме Python2 код, PyDERASN все пак запазва съвместимост с него и поради това има единствена шест зависимост. Освен това, той е тестван спрямо ASN.1:2008 тестов пакет за съответствие.

Принципът на работа с него е аналогичен на pyasn1 — работа с високо ниво на Python обекти. Описанието на ASN.1 схеми е подобно.

class TBSCertificate(Sequence):
    schema = (
        ("version", Version(expl=tag_ctxc(0), default="v1")),
        ("serialNumber", CertificateSerialNumber()),
        ("signature", AlgorithmIdentifier()),
        ("issuer", Name()),
        ("validity", Validity()),
        ("subject", Name()),
        ("subjectPublicKeyInfo", SubjectPublicKeyInfo()),
        ("issuerUniqueID", UniqueIdentifier(impl=tag_ctxp(1), optional=True)),
        ("subjectUniqueID", UniqueIdentifier(impl=tag_ctxp(2), optional=True)),
        ("extensions", Extensions(expl=tag_ctxc(3), optional=True)),
    )

Въпреки това, PyDERASN има подобна на строгата типизация. В pyasn1, ако поле имаше тип CMSVersion(INTEGER), можеше да му се присвои int или INTEGER. PyDERASN строго изисква, присвояваният обект да бъде именно CMSVersion. Освен това, че пишем Python3 код, ние използваме и анотации за типове, затова в нашите функции ще има неразбираеми аргументи като def func(serial, contents), а def func(serial: CertificateSerialNumber, contents: EncapsulatedContentInfo), и PyDERASN помага да се спазва такъв код.

В същото време в PyDERASN има изключително удобни отстъпки на тази самата типизация. pyasn1 не позволяваше в SubjectKeyIdentifier().subtype(implicitTag=Tag(…)) поле да се присвоява SubjectKeyIdentifier() обект (без необходимия IMPLICIT TAG) и често се налагаше да се копират и пресъздават обекти само заради променени IMPLICIT/EXPLICIT тагове. PyDERASN строго следи само основния тип — таговете автоматично се поставят от вече съществуващата схема на ASN.1 структура. Това значително опростява кода на приложенията.

Ако възникне грешка по време на декодиране, в pyasn1 не е просто да се разбере къде точно е възникнала. Например, в споменатия по-горе турски сертификат ще получим следната грешка: UTF8String (tbsCertificate:issuer:rdnSequence:3:0:value:DEFINED BY 2.5.4.10:utf8String) (at 138) unsatisfied bounds: 1 ⇐ 77 ⇐ 64 При написването на ASN.1 структури хората могат да допуснат грешки и това помага по-лесно да се отстраняват проблеми в приложенията или да се изяснят проблемите на кодирани документи от противоположната страна.

В първата версия на PyDERASN нямаше поддръжка на BER кодиране. Тя се появи доста по-късно и все още не се поддържа обработката на UTCTime/GeneralizedTime с часови зони. Това ще дойде в бъдеще, защото проектът се пише основно в свободното от работа време.

В първата версия не беше налична работата с полета DEFINED BY. След няколко месеца тази възможност се появи и започна активно да се използва, което значително намали кода на приложенията — при една операция на декодиране можеше да се получи напълно цялата структура, разгледана до най-дълбоките слоеве. За това, в схемата се определят кои полета какво "определят". Например, описание на схемата CMS:

class ContentInfo(Sequence):
    schema = (
        ("contentType", ContentType(defines=((("content",), {
            id_authenticatedData: AuthenticatedData(),
            id_digestedData: DigestedData(),
            id_encryptedData: EncryptedData(),
            id_envelopedData: EnvelopedData(),
            id_signedData: SignedData(),
        }),))),
        ("content", Any(expl=tag_ctxc(0))),
    )

означава, че ако contentType съдържа OID със стойност id_signedData, то поле content (намиращо се в тази съща SEQUENCE) трябва да бъде декодирано по схемата SignedData. Защо има толкова много скоби? Полето може да "определя" няколко полета едновременно, както е в структурата на EnvelopedData. Определените полета се идентифицират по т.нар. decode path — той задава точното местоположение на всеки елемент във всички структури.

Не винаги искаме или не винаги имаме възможност веднага да внесем тези defines в схемата. Могат да бъдат специфични за приложението случаи, когато OID-ите и структури са известни само в външен проект. PyDERASN предоставя възможност за задаване на тези defines точно в момента на декодиране на структурата:

ContentInfo().decode(data, ctx={"defines_by_path": ((
    (
        "content", DecodePathDefBy(id_signedData),
        "certificates", any, "certificate", "tbsCertificate",
        "extensions", any, "extnID",
    ),
    ((("extnValue",), {
        id_ce_authorityKeyIdentifier: AuthorityKeyIdentifier(),
        id_ce_basicConstraints: BasicConstraints(),
        [...]
        id_ru_subjectSignTool: SubjectSignTool(),
    }),),
),)})

Тук казваме, че в CMS SignedData за всички приложени сертификати, да декодираме всички техни разширения (AuthorityKeyIdentifier, BasicConstraints, SubjectSignTool и т.н.). Указваме чрез decode path, на кой елемент трябва да "вмъкнем" defines, сякаш е зададено в схемата.

Накрая, PyDERASN има възможност за работа от командния ред за декодиране на ASN.1 файлове и има богато pretty printing. Може да се декодира произволен ASN.1 или може да се зададе точно определена схема и да се види нещо подобно:

Показваната информация включва: изместване на обекта, дължина на тага, дължина на съдържанието, наличие на EOC (край на октетите), характеристика на BER-кодиране, характеристика на кодиране с неопределена дължина, дължина и изместване на EXPLICIT таг (ако има), дълбочина на вложеност на обекта в структурата, IMPLICIT/EXPLICIT стойност на тага, име на обекта по схемата, неговия основен ASN.1 тип, пореден номер в SEQUENCE/SET OF, стойност на CHOICE (ако има), четимо име INTEGER/ENUMERATED/BIT STRING по схемата, стойност на произволен основен тип, флаг DEFAULT/OPTIONAL от схемата, характеристика за това, че обектът е автоматично декодиран като DEFINED BY и с какъв OID е свързано, четим OID.

Системата за красиво отпечатване е проектирана така, че генерира последователност от PP-обекти, които се визуализират с помощта на различни средства. На екрана е показан рендерера в прост цвят текст. Има и рендерери в JSON/HTML формат, за да може да се види с подсветка в браузъра на ASN.1 както в asn1js проект.

Други библиотеки

Не беше целта, но PyDERASN стана значително по-бърз от pyasn1. Например, декодирането на CRL файлове с размери от мегабайти може да отнеме толкова дълго време, че ще трябва да се мисли за междинни формати за бързо съхранение на данни и да се променя архитектурата на приложенията. pyasn1 декодира CRL CACert.org на моя лаптоп за повече от 20 минути, докато PyDERASN само за 28 секунди! Има проект asn1crypto, целящ бърза работа с криптографски структури: той декодира (изцяло, а не лениво) същия този CRL за 29 секунди, но използва почти два пъти повече оперативна памет при стартиране под Python3 (983 MiB срещу 498 MiB), и 3.5 пъти повече под Python2 (1677 срещу 488), докато pyasn1 използва цели 4.3 пъти повече (2093 срещу 488).

asn1crypto, който споменах, не разглеждахме, защото проектът все още едва започваше и не бяхме чували за него. Сега също няма да погледнем в неговата посока, тъй като веднага установих, че същият GeneralizedTime не приема произволен формат, а при сериализация мълчаливо премахва стотни от секундата. Това е приемливо за работа с X.509 сертификати, но в общия случай не е подходящо.

В момента, PyDERASN е най-строгият от свободните Python/Go DER декодери, които познавам. В библиотеката encoding/asn1 на любимия ми Go няма стриктна проверка ОБЕКТЕН ИДЕНТИФИКАТОР и UTCTime/GeneralizedTime низи. Понякога строгостта може да пречи (преди всичко, поради обратно съвместимост с по-стари приложения, които никой няма да поправи), затова в PyDERASN по време на декодиране може да се предават различни настройки облекчаващи проверки.

Кодът на проекта се стреми да бъде максимално прост. Цялата библиотека — един файл. Кодът е написан с акцент върху простотата на разбирането, без излишни оптимизации на производителността и DRY-код. В него няма, както вече споменах, поддръжка за пълноценно BER-декодиране на UTCTime/GeneralizedTime низи, както и REAL, RELATIVE OID, EXTERNAL, INSTANCE OF, EMBEDDED PDV и CHARACTER STRING типове данни. Във всички останали случаи лично аз не виждам смисъл да използвам в Python други библиотеки.

Както и всички мои проекти, от типа PyGOST, GoGOST, NNCP, GoVPN, PyDERASN е напълно свободен софтуер, разпространяван при условията на LGPLv3+, и е достъпен за безплатно изтегляне. Има примери за употреба тук и в тестовете на PyGOST.

Сергей Матвеев, шифропанк, член Фонда СПО, Python/Go-разработчик, главен специалист ФГУП «НТЦ „Атлас“.

Източник: habr.com