🥇PyDERASN: kuidas ma kirjutasin ASN.1 teegi slotside ja blobidega

ASN.1 see on standard (ISO, ITU-T, ГОСТ) keeles, mis kirjeldab struktureeritud teavet ja selle teabe kodeerimise reegleid. Minu kui programmeerija jaoks on see lihtsalt veel üks serialiseerimise ja andmete esitamise formaat, nagu JSON, XML, XDR ja teised. See on laialdaselt levinud meie igapäevaelus ning paljud inimestega kokku puutuvad: mobiil- ja telefonivõrgus (UMTS, LTE, WiMAX, SS7, H.323), võrgu protokollides (LDAP, SNMP, Kerberos), kõiges, mis puudutab krüptograafiat (X.509, CMS, PKCS-standardid), pangakaartides ja biometraalsetes passides ning paljus muus.

Selles artiklis käsitletakse PyDERASN: Python ASN.1 raamatukogu, mida kasutatakse aktiivselt krüptograafia projektides Atlas.

Tegelikult ei tohiks ASN.1-d krüptograafiliste ülesannete jaoks soovitada: ASN.1 ja selle kodeerijad on keerulised. See tähendab, et kood ei ole lihtne, mis toob alati kaasa täiendava rünnakusuuna. Piisab vaatamast haavatavuste loendit ASN.1 raamatukogudes. Bruce Schneier oma Cryptography engineering ei soovita samuti seda standardit kasutada selle keerukuse tõttu: "The best-known TLV encoding is ASN.1, but it is incredibly complex and we shy away from it". Kuid kahjuks on meil täna soovitatakse seda standardit mitte kasutada, kuna see on väga keeruline: „Parim teadaolev TLV kodeerimine on ASN.1, kuid see on uskumatult keeruline ja me hoidume sellest.” Kuid kahjuks oleme täna silmitsi avatud võtmete infrastruktuuri , kus seda aktiivselt kasutatakse X.509 sertifika, CRL, OCSP, TSP, CMP protokollid, CMC, sõnumid CMS-i, ja hulk standardeid PKCS. Seetõttu tuleb osata töötada ASN.1-ga, kui tegelete millegagi, mis on seotud krüptograafiaga.

ASN.1 võib olla kodeeritud mitmel viisil/kodeerimisega:

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)

ja palju teisi. Kuid krüptograafilistes ülesannetes kasutatakse praktikas kahte: BER ja DER. Isegi allkirjastatud XML-dokumentides (XMLDSig, XAdES) on ikkagi Base64 kodeeritud ASN.1 DER objektid, nagu ka JSON-põhises protokollis ACME Let’s Encryptist. Kõiki neid kodeerijaid ja kodeerimise põhimõtteid on parem mõista artiklite ja raamatute kaudu: ASN.1 lihtsate sõnadega, ASN.1 — Communication between heterogeneous systems by Olivier Dubuisson, ASN.1 Complete by Prof John Larmouth.

BER on binaarne baitide orientatsiooniga (näiteks PER, populaarne mobiilsides — bitide orientatsiooniga) TLV-formaat. Iga element kodeeritakse järgmiselt: sildi (Tag), mis tuvastab kodeeritava elemendi tüübi (täisarv, string, kuupäev jne), pikkuse (Lsisu pikkust) ja sisu endaVäärt). BER võimaldab valida, kas pöörata tähelepanu pikkusele, seades erilise määramata pikkuse väärtuse ning lõpetades sõnumi End-Of-Octets märgiga. Lisaks pikkuse kodeerimisele on BER-s palju varieeruvusi andmetüüpide kodeerimise viisides, nagu näiteks:

INTEGER, OBJECT IDENTIFIER, BIT STRING ning elemendi pikkus võib olla normaliseerimata (ei ole kodeeritud minimaalses vormis);
BOOLEAN on tõene igasuguste mitte-null sisu puhul;
BIT STRING võib sisaldada "ülejäävaid" nullbite;
BIT STRING, OCTET STRING ja kõik nende tuletatud stringitüübid, sealhulgas kuupäev/aeg, võivad jaguneda muutuva pikkusega osadeks (chunk), mille pikkus on (de)kodeerimise ajal eelnevalt teadmata;
UTCTime/GeneralizedTime võivad omada erinevaid viise ajavööndi nihke määramiseks ja "ülejäävaid" nullsekundeid;
DEFAULT väärtused SEQUENCE's võivad olla kodeeritud või mitte;
Viimaste bitide nimelised väärtused BIT STRING'is võivad soovi korral kodeerimata jääda;
SEQUENCE (OF) / SET (OF) võivad omada elementide suvalist järjekorda.

Kuna eelnevalt mainitud asjaoludest johtuvat, pole alati võimalik andmeid kodeerida nii, et need oleksid originaalse vormiga identsed. Seetõttu loodi reeglite alamkogum: DER — rangelt määratlemine vaid üks lubatud kodeerimise viis, mis on kriitilise tähtsusega krüptograafiliste ülesannete jaoks, kus näiteks üksiku biti muutmine muudab allkirja või kontrollsummat kehtetuks. DER-il on märkimisväärne puudus: kõigi elementide pikkused peavad kodeerimise ajal olema eelnevalt teada, mis ei võimalda andmeid voogesitusena serialiseerida. CER kodeeringul puudub see puudus, tagades samamoodi andmete ühemõttelise esituse. Kahjuks (või õnneks, et meil pole veel keerulisemaid dekoodereid?) ei ole see populaarseks saanud. Seetõttu kohtame praktikas „segatud” kasutust BER ja DER kodeeritud andmetega. Kuna nii CER kui ka DER on BER alamkogud, suudab iga BER-dekooder neid töödelda.

Probleemid pyasn1

Tööl kirjutame me palju programme, mis on seotud krüptograafiaga ja Pythoniga. Mõned aastad tagasi oli tasuta raamatukogude valik praktiliselt olematu: kas olid väga madala tasemega raamatukogud, mis võimaldasid lihtsalt näiteks täisarvu ja struktuuri pealkirja kodeerida/dekodeerida, või oli olemas raamatukogu pyasn1. Me kasutasime seda aastaid ja alguses olime sellega väga rahul, kuna see võimaldab töötada ASN.1 struktuuridega kõrgetasemeliste objektidena: näiteks dekodeeritud X.509 sertifikaadi objektil on võimalik ligipääs oma väljadele sõnaraamivahelise liidese kaudu: cert[«tbsCertificate»][«serialNumber»] näitab meile selle sertifikaadi seerianumbrit. Sarnaselt on võimalik „kokku panna” keerulisi objekte, töötades nendega nagu nimekirjade, sõnaraamatute kaudu ning seejärel lihtsalt kutsuda välja funktsioon pyasn1.codec.der.encoder.encode ja saada dokumendi serialiseeritud esituse.

Kuid probleemide ja piirangud ilmesid. Pyasn1-l olid ja kahjuks on siiani vigu: artikli kirjutamise hetkel dekodeeritakse ja kodeeritakse pyasn1 üks põhiliike — GeneralizedTime, vale viisil.

Meie projektides salvestame sageli ainult faili teed, nihke ja objekti pikkuse baitidesse, millele tahame viidata, et säästa ruumi. Näiteks võib juhuslikult allkirjastatud fail tõenäoliselt asuda CMS SignedData ASN.1 struktuuris:

  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

                 SIIN ON ALLKIRJASTATUD FAILI SISELTUS PIKKUS 751 BAIITI

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

me saame kätte originaalallkirjastatud faili, mille siire on 65 bitti ja pikkus 751 bitti. pyasn1 ei salvestanud seda teavet oma dekodeeritud objektidesse. On kirjutatud nn TLVSeeker — väikene raamatukogu, mis võimaldab dekodeerida siltide ja objektide pikkusi, kus kasutame käsku 'mine järgmisele sildile', 'siseneda sildi sisse' (minnes SEQUENCE objekti sisse), 'mine järgmisele sildile', 'teata oma offset ja objekti pikkus, kus me oleme'. See oli 'käsitsi' navigeerimine ASN.1 DER-serialiseeritud andmete seas. Kuid BER-serialiseeritud andmete puhul ei saanud nii töötada, kuna näiteks oktetstringi bitti järjend võis olla kodeeritud mitme chunk'ina.

Teine probleem meie jaoks pyasn1 puhul on see, et dekodeeritud objektide põhjal ei saa aru, kas antud väli oli SEQUENCE'is kohal või mitte. Näiteks, kui struktuur sisaldab välja Field SEQUENCE OF Smth OPTIONAL, siis see võis täiesti puududa saabunud andmetest (OPTIONAL), aga võis ka olemas olla, kuid samas olla nullpikkusega (tühi nimekiri). Üldiselt ei olnud seda võimalik selgitada. See on vajalik saabunud andmete rangeks kehtivuse kontrollimiseks. Kujutage ette, et mõni sertifitseerimiskeskus väljastas sertifikaadi, millel on ASN.1 skeemi seisukohalt «mitte päris» kehtivad andmed! Näiteks sertifitseerimiskeskus «TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı» ületas oma juuresertifikaadis lubatud piirid. RFC 5280 komponendi subject pikkuse piire — seda ei saa ausalt dekodeerida skeemi järgi. DER kodeerija nõuab, et väli, mille väärtus on DEFAULT, ei kodeeritaks edastamise ajal — selliseid dokumente kohtab praktikas ning PyDERASN esimene versioon isegi teadlikult lubas sellist kehtetut (DER perspektiivist) käitumist tagasiside ühilduvuse nimel.

Veel probleem on see, et ei saa kergesti teada, millises vormis (BER/DER) on antud objekt struktureeritud. Näiteks CMS standard ütleb, et sõnum kodeeritakse BER, kuid allkiri atribuudid, millest luuakse krüptograafiline allkiri, peavad olema DER vormis. Kui dekodeerime DER-iga, siis saame probleemiks CMS-i töötlemisel; kui dekodeerime BER-iga, siis ei tea, missuguses vormis allkiri atribuudid olid. Lõppkokkuvõttes peate leidma iga allkiri atribuudi asukoha TLVSeeker-iga (mida pyasn1-s ei ole) ning dekodeerima need eraldi, tuues need serialiseeritud esitusest välja DER-iga.

Meile oleks väga kasulik olnud automaatne DEFINED BY väljade töötlemine, mida esineb väga sageli. Pärast ASN.1 struktuuri dekodeerimist võivad jääda mitmed ANY väljad, mis peavad olema edasise skeemi kohaselt töödeldud, valitud OBJECT IDENTIFIER-i põhjal, mis on antud struktuuri väljas. Pythonis tähendab see if-lause kirjutamist ja edasist dekooderi kutsumist ANY välja jaoks.

PyDERASN'i ilmumine

Atlassis saadame regulaarselt ülespoole patše, kui leiame mingeid probleeme või arendame kasutatavaid avatud programme. Pyasn1-s oleme mitmel korral teinud täiustusi, kuid pyasn1 kood ei ole kõige kergemini arusaadav ja seal esines aeg-ajalt ühilduvuse muutusi API-s, mis on meid takistanud. Lisaks oleme harjunud kirjutama teste generatiivse testimisega, mida pyasn1-s ei olnud.

Ühel kaunil päeval otsustasin, et on aeg lõpetada selle talumine ja proovida kirjutada oma raamatukogu __slot__-idega, offset-idega ja kenasti kuvandud blob-idega! Lihtsalt ASN.1 kodeerija loomine ei piisanuks — tuleb tõlkida kõik meie omavahel sõltuvad projektid sellele, ja see tähendab sadu tuhandeid koodiridu, mis sisaldavad palju ASN.1 struktuuridega töötamist. Seega üks nõue selle jaoks oli: lihtsus praeguse pyasn1 koodi tõlkimisel. Kulutasin kogu oma puhkuse, et kirjutada see raamatukogu ning tõlkida kõik projektid selle jaoks. Kuna need omavad praktiliselt 100% katvust testidega, tähendas see ka raamatukogu täielikku toimimist.

PyDERASN-l on peaaegu 100%-line katteala testidega. Kasutatakse genereerivat testimist suurepärase teegiga. hypothesis. Samuti viidi läbi fuzzing py-afl-l 32 tuumalistes masinates. Kuigi meil on praktiliselt jäänud vaid vähe Python2 koodi, järgib PyDERASN siiski selle ühilduvust ning seetõttu on tal ainus six sõltuvus. Lisaks on see testitud ASN.1:2008 compliance test suite.

Tööprintsiip on sarnane pyasn1-iga — töötamine kõrgetasemeliste Python objektidega. ASN.1 skeemide kirjeldus on sarnane.

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)),
    )

Kuid PyDERASN-il on sarnasus range tüpiseerimisega. Pyasn1 puhul, kui väljal oli tüüp CMSVersion(INTEGER), sai sellele omistada int või INTEGER. PyDERASN nõuab rangelt, et omistatav objekt oleks just CMSVersion. Lisaks sellele, et kirjutame Python3 koodi, kasutame ka typing annotations, seetõttu on meie funktsioonides arusaamatute argumentide asemel nagu def func(serial, contents) hoopis def func(serial: CertificateSerialNumber, contents: EncapsulatedContentInfo), ning PyDERASN aitab säilitada sellist koodi.

Lisaks pakub PyDERASN äärmiselt mugavaid võimalusi selle sama tüüpide kohandamiseks. pyasn1 ei lubanud SubjectKeyIdentifier().subtype(implicitTag=Tag(…)) väljal määrata SubjectKeyIdentifier() objekti (ilma vajaliku IMPLICIT TAG-ita), mistõttu tuli tihti kopeerida ja taasluua objekte ainult muudetud IMPLICIT/EXPLICIT sildide tõttu. PyDERASN jälgib rangelt ainult põhityüpi — sildid täiendatakse automaatselt olemasolevast ASN.1 struktuuri skeemist. See lihtsustab rakenduste koodi oluliselt.

Kui dekodeerimise ajal tekib viga, on pyasn1-s keeruline mõista, kus see täpselt juhtus. Näiteks juba varem mainitud Türgi sertifikaadiga saame sellise vea: UTF8String (tbsCertificate:issuer:rdnSequence:3:0:value:DEFINED BY 2.5.4.10:utf8String) (at 138) unmet bounds: 1 ⇐ 77 ⇐ 64. ASN.1 struktuuride kirjutamisel võivad inimesed eksida, ja see aitab lihtsustada rakenduste tõrkeotsingut või välja selgitada probleemid vastaspoolte kodeeritud dokumentides.

Esimese versiooni PyDERASN-is ei olnud BER-kodeerimise toetust. See ilmus palju hiljem ja kuni praeguseni ei toetata UTCTime/GeneralizedTime töötlemist ajavöönditega. See tuleb tulevikus, kuna projekt kirjutatakse peamiselt töövälisel ajal.

Samuti ei olnud esimese versiooni puhul DEFINED BY väljadega töötlemist. Mõne kuu pärast see võimalus tekkis ja hakkas aktiivselt kasutama, oluliselt vähendades rakenduste koodi — ühe dekodeerimisoperatsiooni käigus saadakse täielikult lahtiseks muundatud struktuur. Selleks määratakse skeemis, millised väljad mida «määravad». Näiteks skeemi CMS kirjeldus:

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))),
    )

ütleb, et kui contentType sisaldab OID-i väärtusega id_signedData, tuleb content (mis asub samas SEQUENCE'is) dekodeerida skeemi SignedData abil. Miks on nii palju sulge? Väli võib „määrata” mitu väljundit korraga, nagu seda nähakse EnvelopedData struktuurides. Määratletavad väljad tuvastatakse nn dekodeerimise teede kaudu — see määrab igas elemendi täpset asukohta kõigis struktuurides.

Ei pruugi alati soovida või olla võimalik kohe skeemi neid definesid lisada. Võivad olla rakendusespetsiifilised olukorrad, kus OID-id ja struktuurid on teada ainult kolmandas projektis. PyDERASN võimaldab määrata neid definesid otse struktuuri dekodeerimise hetkel:

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(),
    }),),
),)})

Siin räägime, et CMS SignedData jaoks tuleks dekodeerida kõik manustatud sertifikaadid ja nende laiendused (AuthorityKeyIdentifier, BasicConstraints, SubjectSignTool jne). Me määrame dekodeerimise teel, millisele elemendile tuleks „asetada” defines, justkui oleks see määratud skeemis.

Lõpuks võimaldab PyDERASN töötada käsku rea kaudu ASN.1 failide dekodeerimiseks ning sellel on rikkalik ilus trükkimine. Saab dekodeerida suvalist ASN.1 formaati või määrata selgelt määratud skeemi ja näha midagi sellist:

Kuvatud teave: objekti nihke, sildi pikkus, pikkuse pikkus, sisu pikkus, EOC (octetite lõpp) olemasolu, BER-kodeerimise tunnus, määramata pikkuse kodeerimise tunnus, EXPLICIT sildi pikkus ja nihke (kui on), objekti sügavus struktuurides, IMPLICIT/EXPLICIT sildi väärtus, objekti nimi skeemi järgi, selle põhi ASN.1 tüüp, järjestuse/koosseisu sees olev järjekorranumber, CHOICE väärtus (kui on), inimese loetav INTEGER/ENUMERATED/BIT STRING nimi skeemi järgi, mis tahes põhityüpide väärtus, skeemilt DEFAULT/OPTIONAL lipp, tunnus, et objekt dekodeeriti automaatselt kui DEFINED BY ning millise OID-i tõttu see juhtus, inimese loetav OID.

Pretty printing süsteem on loodud genereerima PP-objektide järjekordi, mis visualiseeritakse juba eraldiseisvate vahendite kaudu. Screenshot'il on näha renderdaja lihtsas värvilises tekstis. On olemas ka JSON/HTML formaadis renderdaid, et seda saaks brauseris ASN.1-i esitlemisega näha nagu asn1js projektis.

Teised teegid

See ei olnud eesmärk, kuid PyDERASN osutus oluliselt kiiremaks kui pyasn1. Näiteks CRL-failide dekodeerimine megabaidise suurusega võib võtta nii kaua aega, et tuleb mõelda andmete salvestamise (kiirete) vaheformaadi kasutamisele ja rakenduste arhitektuuri muutmisele. pyasn1 dekodeerib CRL CACert.org mu sülearvutis üle 20 minuti, samas kui PyDERASN vaid 28 sekundiga! On projekt asn1crypto, mis keskendub krüptograafiliste struktuuridega kiirele töötlemisele: see dekodeerib (täielikult, mitte laiskalt) sama CRL 29 sekundiga, kuid kasutab käivitamisel Python3 all peaaegu kaks korda rohkem mälu (983 MiB võrreldes 498 MiB), ja 3.5 korda rohkem Python2 all (1677 võrreldes 488), samas kui pyasn1 kasutab lausa 4.3 korda rohkem (2093 võrreldes 488).

asn1crypto, mida mainisin, me ei arutanud, sest projekt oli alles alguses ja me ei olnud sellest kuulnud. Praegu ei vaataks ka me selle poole, kuna märkasin kohe, et sama GeneralizedTime ei aktsepteeri suvalist vormingut ja serialiseerimise käigus eemaldab ta vaikselt kordajaid. See on vastuvõetav X.509 sertifikaatidega töötamiseks, kuid üldiselt ei sobi.

Praegu on PyDERASN kõige rangem vabalt saadaval olev Python/Go DER-dekooder, mida ma tunnen. Minu lemmik Go encoding/asn1 teegis ei ole range kontroll OBJECT IDENTIFIER ja UTCTime/GeneralizedTime stringide jaoks. Mõnikord võib rangeus segada (peamiselt vanade rakendustega ühilduvuse tõttu, mida keegi ei hakka parandama), seega saab PyDERASN-is dekodeerimise ajal edastada erinevaid seadeid kontrollide leevendamiseks.

Projekti kood püüab olla võimalikult lihtne. Kõik raamatukogu on üks fail. Kood on kirjutatud arusaadavuse rõhuga, ilma liigsete jõudluse optimeerimisteta ja DRY-koodita. Nagu juba mainitud, ei sisalda see täielikku BER dekodeerimist UTCTime/GeneralizedTime stringide jaoks, samuti REAL, RELATIVE OID, EXTERNAL, INSTANCE OF, EMBEDDED PDV, CHARACTER STRING andmetüüpe. Kõigil muudel juhtudel ei näe ma isiklikult mõtet Pythonis kasutada teisi raamatukogusid.

Nagu kõik mu projektid, nagu PyGOST, GoGOST, NNCP, GoVPN, PyDERASN on täiesti avamood, mida levitatakse LGPLv3+, ja saadaval tasuta allalaadimiseks. Kasutamise näiteid leidub siin ja PyGOST testides.

Sergei Matvejev, krüptopank, liige SPO Fondist, Python/Go arendaja, peaspetsialist FGUP „NTC Atlaas“.

Allikas: habr.com