PyDERASN: как създадох ASN.1 библиотека с slots and blobs

ASN.1 е стандарт (ISO, ITU-T, ГОСТ) за описание на структурирана информация и правилата за нейното кодиране. За мен като програмист, това е просто още един формат за сериализация и представяне на данни, наред с JSON, XML, XDR и други. Той е изключително разпространен в ежедневието ни и много хора се сблъскват с него: в мобилни, телефонни и VoIP комуникации (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 също не препоръчва използването на този стандарт заради неговата сложност: «Най-известният TLV кодек е ASN.1, но е неизмеримо сложен и се оттегляме от него». Но, за съжаление, днес имаме инфраструктури за открит ключ в които активно се използват 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 — Communication between heterogeneous systems от Оливие Дюбуасон, ASN.1 Complete от професор Джон Лармут.

BER е бинарен байт-ориентиран (например PER, популярен в мобилната комуникация — бит-ориентиран) TLV формат. Всеки елемент се кодира под формата на: етикет (Tтип на кодирния елемент (цяло число, низ, дата и т.н.), дължина (Lдължина) на съдържанието и самото съдържание (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 bytes
                     . . . . . . 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), "премини към следващия етикет", "съобщи своето отместване и дължина на обекта, където се намираме". Това беше "ръчно" преминаване през ASN.1 DER-сериализирани данни. Но така не можеше да се работи с BER-сериализирани данни, тъй като, например, байтовата низ OCTET STRING може да е била кодирана в няколко парчета.

Друг недостатък за нашите нужди 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-и и прекрасно представени blob-ове! Просто създаването на ASN.1 кодек би било недостатъчно — необходимо беше да пренасочим всички наши взаимозависими проекти към него, а това са стотици хиляди редове код, в които има много работа с ASN.1 структури. Тоест, едно от изискванията за него е: леснота в прехвърлянето на текущия код на pyasn1. Прекарах целия си отпуск, за да напиша тази библиотека и пренасочих всички проекти към нея. Тъй като те имат практически 100%-но покритие с тестове, това означаваше и пълна работоспособност на библиотеката.

PyDERASN също така има практически 100%-но покритие с тестове. Използва се генеративно тестване с невероятната библиотека hypothesis. Проведоха се и fuzzing py-afl- на 32-ядрени машини. Въпреки че почти не ни остава код на Python2, PyDERASN все още поддържа съвместимост с него и поради това има единствена шест зависимост. Освен това, той е тестван спрямо ASNI.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 с часови зони. Това ще дойде в бъдеще, тъй като проектът се пише основно в свободното време.

В първата версия не беше възможно да се работи с полета, дефинирани от полетата. След няколко месеца тази възможност се появи и започна активно да се използва, значително съкращавайки кода на приложенията — с една операция на декодиране можеше да се получи напълно цялата структура, разгледана дълбоко. За това, в схемата се задават кои полета какво «определят». Например, описание на схемата 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), и 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, характерни низове типове данни. Във всичките останали случаи, лично за мен няма смисъл да се използват други библиотеки в Python.

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

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

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