🥇PyDERASN: मी स्लॉट आणि ब्लॉबसह ASN.1 लायब्ररी कशी लिहिली

ASN.1 हे संरचित माहितीचे वर्णन करणार्‍या भाषेचे मानक (ISO, ITU-T, GOST) आहे, तसेच ही माहिती एन्कोड करण्याचे नियम आहे. माझ्यासाठी, प्रोग्रामर म्हणून, जेएसओएन, एक्सएमएल, एक्सडीआर आणि इतरांसह डेटा क्रमबद्ध करण्यासाठी आणि सादर करण्यासाठी हे दुसरे स्वरूप आहे. आपल्या दैनंदिन जीवनात हे अत्यंत सामान्य आहे आणि अनेकांना याचा सामना करावा लागतो: सेल्युलर, टेलिफोन, VoIP कम्युनिकेशन्स (UMTS, LTE, WiMAX, SS7, H.323), नेटवर्क प्रोटोकॉलमध्ये (LDAP, SNMP, Kerberos), प्रत्येक गोष्टीत क्रिप्टोग्राफी (X.509, CMS, PKCS मानके), बँक कार्ड आणि बायोमेट्रिक पासपोर्टमध्ये आणि बरेच काही.

हा लेख संबंधित आहे PyDERASN: Python ASN.1 लायब्ररी मधील क्रिप्टोग्राफीशी संबंधित प्रकल्पांमध्ये सक्रियपणे वापरली जाते नकाशांचे पुस्तक.

सर्वसाधारणपणे, क्रिप्टोग्राफिक कार्यांसाठी ASN.1 ची शिफारस करणे योग्य नाही: ASN.1 आणि त्याचे कोडेक्स जटिल आहेत. याचा अर्थ असा की कोड साधा नसेल आणि हा नेहमीच अतिरिक्त हल्ला वेक्टर असतो. जरा बघा यादीत ASN.1 लायब्ररीमधील भेद्यता. त्याच्या मध्ये ब्रूस Schneier क्रिप्टोग्राफी अभियांत्रिकी हे मानक त्याच्या जटिलतेमुळे वापरण्याविरुद्ध सल्ला देते: "सर्वोत्तम ज्ञात TLV एन्कोडिंग ASN.1 आहे, परंतु ते आश्चर्यकारकपणे जटिल आहे आणि आम्ही त्यापासून दूर जातो." पण, दुर्दैवाने आज आपल्याकडे आहे सार्वजनिक की पायाभूत सुविधा ज्यामध्ये ते सक्रियपणे वापरले जातात X.509 प्रमाणपत्रे, CRL, OCSP, TSP, CMP प्रोटोकॉल, प्रतिस्पधीर्, संदेश CMS, आणि बरेच मानक PKCS. म्हणून, जर तुम्ही क्रिप्टोग्राफीशी संबंधित काहीही करत असाल तर तुम्हाला ASN.1 सह कार्य करण्यास सक्षम असणे आवश्यक आहे.

ASN.1 विविध प्रकारे/कोडेक्समध्ये एन्कोड केले जाऊ शकते:

बीईआर (मूलभूत एन्कोडिंग नियम)
सीईआर (प्रामाणिक एन्कोडिंग नियम)
DER (विशिष्ट एन्कोडिंग नियम)
जीएसईआर (जेनेरिक स्ट्रिंग एन्कोडिंग नियम)
जेईआर (JSON एन्कोडिंग नियम)
LWER (हलके वजन एन्कोडिंग नियम)
REO (ऑक्टेट एन्कोडिंग नियम)
PER (पॅक केलेले एन्कोडिंग नियम)
SER (विशिष्ट एन्कोडिंग नियमांचे संकेत)
शिष्य (XML एन्कोडिंग नियम)

आणि इतर अनेक. परंतु क्रिप्टोग्राफिक कार्यांमध्ये, व्यवहारात, दोन वापरले जातात: BER आणि DER. स्वाक्षरी केलेल्या XML दस्तऐवजांमध्ये देखील (XMLDSig, XAdES) अजूनही बेस64-एनकोड केलेले ASN.1 DER ऑब्जेक्ट्स असतील, जसे की JSON-भिमुख प्रोटोकॉलमध्ये एसीएमई चला एन्क्रिप्ट करू. तुम्ही लेख आणि पुस्तकांमधील हे सर्व कोडेक्स आणि BER/CER/DER कोडिंग तत्त्वे अधिक चांगल्या प्रकारे समजून घेऊ शकता: ASN.1 सोप्या शब्दात, ASN.1 — ऑलिव्हियर डुब्युसन द्वारे विषम प्रणालींमधील संप्रेषण, ASN.1 प्रोफेसर जॉन लार्माउथ द्वारे पूर्ण.

BER हे बायनरी बाइट-ओरिएंटेड आहे (उदाहरणार्थ PER, सेल्युलर कम्युनिकेशन्समध्ये लोकप्रिय - बिट-ओरिएंटेड) TLV फॉरमॅट. प्रत्येक घटक याप्रमाणे एन्कोड केलेला आहे: टॅग (Tएजी), एन्कोड करावयाच्या घटकाचा प्रकार ओळखणे (पूर्णांक, स्ट्रिंग, तारीख इ.), लांबी (Length) सामग्री आणि सामग्री स्वतः (Value). BER वैकल्पिकरित्या तुम्हाला एक विशेष अनिश्चित लांबीचे मूल्य सेट करून आणि एंड-ऑफ-ऑक्टेट्स संदेशाला एंड-ऑफ-ऑक्टेट्स चिन्हासह समाप्त करून लांबीचे मूल्य निर्दिष्ट न करण्याची परवानगी देते. लांबीच्या एन्कोडिंग व्यतिरिक्त, BER मध्ये डेटा प्रकार एन्कोड करण्याच्या पद्धतीमध्ये बरीच परिवर्तनशीलता आहे, जसे की:

पूर्णांक, ऑब्जेक्ट आयडेंटिफायर, BIT स्ट्रिंग आणि घटकांची लांबी सामान्यीकृत केली जाऊ शकत नाही (किमान स्वरूपात एन्कोड केलेली नाही);
BOOLEAN कोणत्याही शून्य नसलेल्या सामग्रीसाठी सत्य आहे;
BIT STRING मध्ये "अतिरिक्त" शून्य बिट्स असू शकतात;
BIT STRING, OCTET STRING आणि त्यांचे सर्व व्युत्पन्न स्ट्रिंग प्रकार, तारीख/वेळेसह, व्हेरिएबल-लांबीच्या भागांमध्ये मोडले जाऊ शकतात, ज्याची लांबी (डी)एनकोडिंगच्या वेळी आधीच माहित नसते;
UTCTtime/GeneralizedTime मध्ये टाइम झोन ऑफसेट आणि सेकंदांचे "अतिरिक्त" शून्य अपूर्णांक निर्दिष्ट करण्याचे वेगवेगळे मार्ग असू शकतात;
डीफॉल्ट अनुक्रम मूल्ये एन्कोड केली जाऊ शकतात किंवा नसू शकतात;
BIT STRING मधील शेवटच्या बिट्सची नामित मूल्ये वैकल्पिकरित्या अनकोड केली जाऊ शकतात;
SEQUENCE (OF)/SET (OF) मध्ये घटकांचा कोणताही क्रम असू शकतो.

वरील सर्व गोष्टींमुळे, डेटा एन्कोड करणे जेणेकरुन ते मूळ स्वरूपासारखेच असेल असे नेहमीच शक्य नसते. म्हणून, नियमांचा एक उपसंच शोधला गेला: DER - फक्त एक वैध एन्कोडिंग पद्धतीचे काटेकोरपणे नियमन करणे, जी क्रिप्टोग्राफिक कार्यांसाठी महत्त्वपूर्ण आहे जेथे, उदाहरणार्थ, एक बिट बदलल्याने स्वाक्षरी किंवा चेकसम अवैध होईल. DER चा एक महत्त्वपूर्ण तोटा आहे: सर्व घटकांची लांबी एन्कोडिंगच्या वेळी आधीच ओळखली जाणे आवश्यक आहे, जे डेटाच्या प्रवाहाच्या क्रमवारीला परवानगी देत नाही. CER कोडेकमध्ये ही कमतरता नाही, त्याचप्रमाणे डेटाच्या अस्पष्ट प्रतिनिधित्वाची हमी देते. दुर्दैवाने (किंवा हे भाग्यवान आहे की आमच्याकडे आणखी जटिल डीकोडर नाहीत?), ते लोकप्रिय झाले नाही. म्हणून, व्यवहारात आम्हाला BER आणि DER एन्कोडेड डेटाचा "मिश्र" वापर आढळतो. CER आणि DER दोन्ही BER चे उपसंच असल्याने, कोणताही BER डिकोडर त्यांना हाताळू शकतो.

pyasn1 सह समस्या

कामावर आम्ही क्रिप्टोग्राफीशी संबंधित बरेच पायथन प्रोग्राम लिहितो. आणि काही वर्षांपूर्वी विनामूल्य लायब्ररींचा व्यावहारिकदृष्ट्या कोणताही पर्याय नव्हता: एकतर ही अत्यंत निम्न-स्तरीय लायब्ररी आहेत जी तुम्हाला फक्त एन्कोड/डीकोड करण्याची परवानगी देतात, उदाहरणार्थ, पूर्णांक आणि रचना शीर्षलेख किंवा ही लायब्ररी pyasn1. आम्ही त्यावर अनेक वर्षे जगलो आणि सुरुवातीला आम्हाला खूप आनंद झाला, कारण ते तुम्हाला उच्च-स्तरीय वस्तूंप्रमाणे ASN.1 स्ट्रक्चर्ससह कार्य करण्यास अनुमती देते: उदाहरणार्थ, डीकोड केलेले X.509 प्रमाणपत्र ऑब्जेक्ट तुम्हाला त्याच्या फील्डमध्ये प्रवेश करण्यास अनुमती देते. शब्दकोश इंटरफेस: प्रमाणपत्र[“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 मध्ये उपस्थित होते की नाही हे समजण्यास असमर्थता. उदाहरणार्थ, जर स्ट्रक्चरमध्ये Smth OPTIONAL फील्डचा फील्ड SEQUENCE असेल, तर तो इनकमिंग डेटामधून पूर्णपणे अनुपस्थित असू शकतो (OPTIONAL), किंवा तो उपस्थित असू शकतो, परंतु शून्य लांबीचा असू शकतो (रिकामी सूची). सर्वसाधारणपणे, हे निश्चित केले जाऊ शकत नाही. आणि प्राप्त डेटाच्या वैधतेच्या कठोर सत्यापनासाठी हे आवश्यक आहे. कल्पना करा की काही प्रमाणन प्राधिकरण डेटासह एक प्रमाणपत्र जारी करेल जे ASN.1 योजनांच्या दृष्टिकोनातून "संपूर्णपणे" वैध नाही! उदाहरणार्थ, प्रमाणन प्राधिकरण “TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” ने त्याच्या मूळ प्रमाणपत्रात अनुज्ञेय मर्यादा ओलांडल्या आहेत आरएफसी 5280 विषय घटकाच्या लांबीवर मर्यादा - ते योजनेनुसार प्रामाणिकपणे डीकोड केले जाऊ शकत नाही. डीईआर कोडेकला आवश्यक आहे की ज्या फील्डचे मूल्य डीफॉल्टच्या बरोबरीचे आहे ते ट्रांसमिशन दरम्यान एन्कोड केलेले नाही - असे दस्तऐवज आयुष्यात घडतात आणि PyDERASN च्या पहिल्या आवृत्तीने जाणूनबुजून अशा अवैध (डीआरच्या दृष्टिकोनातून) वर्तनास परवानगी दिली आहे. मागास सहत्वता.

दुसरी मर्यादा म्हणजे संरचनेत विशिष्ट ऑब्जेक्ट कोणत्या स्वरूपात (BER/DER) एन्कोड केले आहे हे सहजपणे शोधण्यात अक्षमता आहे. उदाहरणार्थ, CMS मानक म्हणते की संदेश BER-एनकोड केलेला आहे, परंतु signedAttrs फील्ड, ज्यावर क्रिप्टोग्राफिक स्वाक्षरी तयार केली जाते, DER मध्ये असणे आवश्यक आहे. आम्ही DER सह डीकोड केल्यास, आम्ही CMS च्या प्रक्रियेतच अयशस्वी होऊ; आम्ही BER सह डीकोड केल्यास, स्वाक्षरी केलेलेAttrs कोणत्या स्वरूपात होते हे आम्हाला कळणार नाही. परिणामी, TLVSeeker (ज्याला pyasn1 मध्ये कोणतेही analogue नाही) प्रत्येक स्वाक्षरी केलेल्याAttrs फील्डचे स्थान शोधावे लागेल, आणि स्वतंत्रपणे, ते अनुक्रमित प्रतिनिधित्वातून बाहेर काढून, DER सह डीकोड करावे लागेल.

स्वयंचलितपणे परिभाषित केलेल्या फील्ड्सवर प्रक्रिया करण्याची क्षमता, जे बर्याचदा घडते, आमच्यासाठी खूप इष्ट होते. ASN.1 रचना डीकोड केल्यानंतर, आमच्याकडे अनेक फील्ड शिल्लक राहू शकतात ज्यावर संरचना फील्डमध्ये निर्दिष्ट केलेल्या ऑब्जेक्ट आयडेंटिफायरवर आधारित निवडलेल्या योजनेनुसार पुढील प्रक्रिया करणे आवश्यक आहे. पायथन कोडमध्ये, याचा अर्थ कोणत्याही फील्डसाठी डीकोडरला इफ आणि नंतर कॉल करणे असा अर्थ आहे.

PyDERASN चा उदय

अॅटलसमध्ये, जेव्हा आम्हाला काही समस्या आढळतात किंवा आम्ही वापरत असलेल्या विनामूल्य प्रोग्राममध्ये सुधारणा करतो तेव्हा आम्ही नियमितपणे शीर्षस्थानी पॅच पाठवतो. आम्ही pyasn1 मध्ये अनेक वेळा सुधारणा सबमिट केल्या, परंतु pyasn1 चा कोड समजण्यास सर्वात सोपा नाही आणि काहीवेळा विसंगत API बदल होते ज्यामुळे आम्हाला हरवले. शिवाय, आम्हाला जनरेटिव्ह चाचणीसह चाचण्या लिहिण्याची सवय आहे, जी pyasn1 मध्ये नव्हती.

एका चांगल्या दिवशी मी ठरवले की माझ्याकडे ते पुरेसे आहे आणि माझी स्वतःची लायब्ररी __slot__s, ऑफसेट आणि सुंदर प्रदर्शित केलेल्या ब्लॉबसह लिहिण्याचा प्रयत्न करण्याची वेळ आली आहे! फक्त एक ASN.1 कोडेक तयार करणे पुरेसे नाही - आम्हाला आमचे सर्व अवलंबून असलेले प्रकल्प त्यावर हस्तांतरित करणे आवश्यक आहे आणि या कोडच्या शेकडो हजारो ओळी आहेत ज्या ASN.1 स्ट्रक्चर्ससह पूर्ण आहेत. म्हणजेच, त्यासाठी आवश्यक असलेली एक: सध्याच्या pyasn1 कोडचे भाषांतर सुलभ करणे. माझी सर्व सुट्टी घालवल्यानंतर, मी ही लायब्ररी लिहिली आणि सर्व प्रकल्प त्यात हस्तांतरित केले. त्यांच्याकडे चाचण्यांसह जवळजवळ 100% कव्हरेज असल्याने, याचा अर्थ लायब्ररी पूर्णपणे कार्यरत आहे.

PyDERASN, त्याचप्रमाणे, जवळजवळ 100% चाचणी कव्हरेज आहे. उत्कृष्ट लायब्ररीसह जनरेटिव्ह चाचणी वापरते गृहित कल्पना. तीही पार पडली अस्पष्ट py-afl- मी 32 आण्विक मशीनवर खातो. आमच्याकडे व्यावहारिकदृष्ट्या कोणताही Python2 कोड शिल्लक नसला तरीही, PyDERASN अजूनही त्याच्याशी सुसंगतता राखतो आणि यामुळे फक्त सहा व्यसन शिवाय, त्याची चाचणी केली जाते ASN.1:2008 अनुपालन चाचणी संच.

त्याच्यासह कार्य करण्याचे सिद्धांत pyasn1 सारखे आहे - उच्च-स्तरीय पायथन ऑब्जेक्ट्ससह कार्य करणे. 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(सिरियल, कंटेंट) सारखे अस्पष्ट वितर्क नसतील, परंतु def func(सिरियल: CertificateSerialNumber, सामग्री: 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) (138 वर) असमाधानी सीमा: 1 ⇐ 77 ⇐ 64 ASN .1 रचना लिहिताना लोक चुका करू शकतात आणि यामुळे अनुप्रयोग डीबग करणे किंवा इतर पक्षाच्या कोडेड दस्तऐवजांसह समस्या शोधणे सोपे होते.

PyDERASN ची पहिली आवृत्ती BER एन्कोडिंगला समर्थन देत नाही. हे खूप नंतर दिसले आणि तरीही वेळ क्षेत्रांसह UTCTtime/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 मध्ये id_signedData मूल्यासह OID असेल, तर सामग्री फील्ड (त्याच SEQUENCE मध्ये स्थित) SignedData योजनेनुसार डीकोड करणे आवश्यक आहे. इतके कंस का आहेत? एखादे फील्ड एकाच वेळी अनेक फील्ड "परिभाषित" करू शकते, जसे EnvelopedData संरचनांमध्ये आहे. परिभाषित फील्ड तथाकथित डीकोड मार्गाने ओळखले जातात - ते सर्व संरचनांमधील कोणत्याही घटकाचे अचूक स्थान निर्दिष्ट करते.

तुम्हाला नेहमी नको असते किंवा तुम्हाला नेहमी डायग्राममध्ये या व्याख्या जोडण्याची संधी नसते. अनुप्रयोग-विशिष्ट प्रकरणे असू शकतात जेव्हा OIDs आणि संरचना केवळ तृतीय-पक्षाच्या प्रकल्पामध्ये ओळखल्या जातात. PyDERASN रचना डीकोडिंगच्या वेळी या व्याख्या सेट करण्याची क्षमता प्रदान करते:

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, इ.). आम्ही डीकोड मार्गाद्वारे सूचित करतो की कोणता घटक परिभाषितांसह "बदल" करणे आवश्यक आहे, जसे की ते स्कीमामध्ये निर्दिष्ट केले आहे.

शेवटी, PyDERASN कडून पळण्याची क्षमता आहे कमांड लाइन ASN.1 फायली डीकोड करण्यासाठी आणि समृद्ध आहे सुंदर छपाई. तुम्ही एक अनियंत्रित ASN.1 डीकोड करू शकता किंवा तुम्ही स्पष्टपणे परिभाषित योजना निर्दिष्ट करू शकता आणि असे काहीतरी पाहू शकता:

प्रदर्शित माहिती: ऑब्जेक्ट ऑफसेट, टॅगची लांबी, लांबीची लांबी, सामग्रीची लांबी, EOC ची उपस्थिती (ऑक्टेट्सचा शेवट), BER एन्कोडिंग विशेषता, अनिश्चित-लांबीची एन्कोडिंग विशेषता, EXPLICIT टॅगची लांबी आणि ऑफसेट (असल्यास), ऑब्जेक्ट नेस्टिंग खोली रचनांमध्ये, IMPLICIT/EXPLICIT टॅग मूल्य, योजनेनुसार ऑब्जेक्टचे नाव, त्याचा आधार ASN.1 प्रकार, SEQUENCE/SET OF मधील अनुक्रम क्रमांक, निवड मूल्य (असल्यास), मानवी वाचनीय नाव पूर्णांक/गणित/बिट स्ट्रिंग त्यानुसार स्कीम, कोणत्याही बेस प्रकाराचे मूल्य , स्कीममधील डीफॉल्ट/ऐच्छिक ध्वज, ऑब्जेक्ट आपोआप परिभाषित द्वारे डीकोड केले असल्याचे चिन्ह आणि ज्या OID मुळे हे घडले, मानवी वाचनीय OID.

सुंदर छपाई प्रणाली विशेषतः डिझाइन केलेली आहे जेणेकरून ती PP ऑब्जेक्ट्सचा एक क्रम तयार करते जी स्वतंत्र माध्यमांचा वापर करून दृश्यमान केली जाते. स्क्रीनशॉट साध्या रंगीत मजकुरात प्रस्तुतकर्ता दर्शवितो. JSON/HTML फॉरमॅटमध्ये रेंडरर देखील आहेत, जेणेकरून ते ASN.1 ब्राउझरमध्ये हायलाइटिंगसह पाहिले जाऊ शकते, जसे की asn1js प्रकल्प

इतर लायब्ररी

हे ध्येय नव्हते, परंतु PyDERASN लक्षणीयरित्या बाहेर पडले जलद pyasn1 पेक्षा. उदाहरणार्थ, मेगाबाइट आकाराच्या CRL फाइल्स डीकोड करण्यासाठी इतका वेळ लागू शकतो की तुम्हाला इंटरमीडिएट डेटा स्टोरेज फॉरमॅट्स (जलद) बद्दल विचार करावा लागेल आणि अॅप्लिकेशन आर्किटेक्चर बदलावे लागेल. pyasn1 CRL डीकोड करते CACert.org माझ्या लॅपटॉपवर 20 मिनिटांपेक्षा जास्त वेळ लागतो, तर PyDERASN ला फक्त 28 सेकंद लागतात! एक प्रकल्प आहे asn1crypto, क्रिप्टोग्राफिक स्ट्रक्चर्ससह जलद काम करण्याच्या उद्देशाने: ते 29 सेकंदात समान CRL डीकोड करते (पूर्णपणे, आळशीपणे नाही), परंतु Python3 (983 MiB विरुद्ध 498) अंतर्गत चालत असताना जवळजवळ दुप्पट RAM वापरते आणि Python3.5 (2) अंतर्गत 1677 पटीने वापरते. विरुद्ध 488), तर pyasn1 4.3 पट जास्त वापरते (2093 विरुद्ध 488).

आम्ही asn1crypto विचारात घेतले नाही, ज्याचा मी उल्लेख केला आहे, कारण प्रकल्प अद्याप बाल्यावस्थेत होता आणि आम्ही त्याबद्दल ऐकले नव्हते. आता आम्ही त्याच्या दिशेनेही पाहणार नाही, कारण मला लगेच आढळले की समान जनरलाइज्ड टाइम अनियंत्रित फॉर्म घेत नाही आणि सीरियलायझेशन दरम्यान ते शांतपणे सेकंदाचा एक अंश काढून टाकते. हे X.509 प्रमाणपत्रांसह कार्य करण्यासाठी स्वीकार्य आहे, परंतु सर्वसाधारणपणे ते कार्य करणार नाही.

याक्षणी, PyDERASN हा मला माहीत असलेला सर्वात कठोर मोफत Python/Go DER डीकोडर आहे. माझ्या प्रिय गो च्या एन्कोडिंग/asn1 लायब्ररीमध्ये कठोर तपासणी नाही ऑब्जेक्ट आयडेंटिफायर आणि UTCTtime/GeneralizedTime स्ट्रिंग्स. काहीवेळा काटेकोरपणा मार्गात येऊ शकतो (प्रामुख्याने जुन्या ऍप्लिकेशन्सच्या मागास अनुकूलतेमुळे जे कोणीही निराकरण करणार नाही), त्यामुळे PyDERASN पास होऊ शकते विविध सेटिंग्ज कमकुवत तपासण्या.

प्रकल्प कोड शक्य तितका सोपा करण्याचा प्रयत्न करतो. संपूर्ण लायब्ररी ही एक फाईल आहे. अनावश्यक कार्यप्रदर्शन ऑप्टिमायझेशन आणि DRY कोड शिवाय, समजून घेण्याच्या सुलभतेवर भर देऊन कोड लिहिलेला आहे. मी आधीच म्हटल्याप्रमाणे, ते UTCTime/GeneralizedTime स्ट्रिंग्सच्या पूर्ण BER डिकोडिंगला, तसेच REAL, RELATIVE OID, EXTERNAL, INSTANCE OF, एम्बेडेड PDV, कॅरेक्टर स्ट्रिंग डेटा प्रकारांना समर्थन देत नाही. इतर सर्व प्रकरणांमध्ये, मला वैयक्तिकरित्या पायथनमधील इतर लायब्ररी वापरण्याचा मुद्दा दिसत नाही.

माझे सर्व प्रकल्प आवडले, आवडले PyGOST, GoGOST, एनएनसीपी, GoVPN, PyDERASN पूर्णपणे आहे मोफत सॉफ्टवेअर, अटी अंतर्गत वितरित LGPLv3+, आणि विनामूल्य डाउनलोडसाठी उपलब्ध आहे. वापरण्याची उदाहरणे आहेत येथे आणि मध्ये PyGOST चाचण्या.

सेर्गेई मॅटवीव, सायफरपंक, सदस्य SPO फाउंडेशन, पायथन/गो डेव्हलपर, मुख्य तज्ञ FSUE "STC "ऍटलस".

स्त्रोत: www.habr.com

PyDERASN: मी स्लॉट आणि ब्लॉबसह ASN.1 लायब्ररी कशी लिहिली

pyasn1 सह समस्या

PyDERASN चा उदय

इतर लायब्ररी

एक टिप्पणी जोडा Отменить ответ