PyDERASN: スロットと BLOB を含む ASN.1 ライブラリを作成した方法

ASN.1 これは、構造化情報を記述する言語の標準 (ISO、ITU-T、GOST) と、この情報をエンコードするための規則です。 プログラマーである私にとって、これは、JSON、XML、XDR などと同様に、データをシリアル化して表示するための単なる別の形式です。 これは私たちの日常生活の中で非常に一般的であり、携帯電話、電話、VoIP 通信 (UMTS、LTE、WiMAX、SS7、H.323)、ネットワーク プロトコル (LDAP、SNMP、Kerberos) など、あらゆるもので多くの人が遭遇しています。これは、銀行カードや生体認証パスポートなどの暗号化 (X.509、CMS、PKCS 標準) に関係します。

この記事では ピデラスン: Python ASN.1 ライブラリは、暗号化に関連するプロジェクトで積極的に使用されています。 アトラス.

一般に、ASN.1 は暗号化タスクに推奨する価値はありません。ASN.1 とそのコーデックは複雑です。 これは、コードが単純ではなくなり、常に追加の攻撃ベクトルとなることを意味します。 ちょっと見てください リストへ ASN.1 ライブラリの脆弱性。 ブルース・シュナイアーの著書 暗号工学 また、その複雑さからこの標準を使用しないようにアドバイスしています。「最もよく知られている TLV エンコーディングは ASN.1 ですが、信じられないほど複雑なので、私たちはそれを避けています。」 しかし、残念ながら今日は、 公開鍵インフラストラクチャ 積極的に使用されている場所 X.509証明書、CRL、OCSP、TSP、CMP プロトコル、 CMC、メッセージ と組み合わせた、シンプルで高性能なLC / MSシステム、および多くの規格 PKCS。 したがって、暗号化に関連する作業を行う場合は、ASN.1 を使用できる必要があります。

ASN.1 は、さまざまな方法/コーデックでエンコードできます。

• BER (基本的なエンコード規則)
• CER (正規のエンコーディング規則)
• DER (区別された符号化規則)
• GSER (一般的な文字列エンコード規則)
• JER (JSONエンコードルール)
• LWER (軽量エンコーディング ルール)
• OER (オクテット符号化規則)
• FOR (パックされたエンコード規則)
• SER (シグナリング固有のエンコーディング ルール)
• 弟子たち (XMLエンコーディング規則)

他にも多数。 しかし、暗号化タスクでは、実際には BER と DER の XNUMX つが使用されます。 署名された XML ドキュメントでも (XMLDSig, ザデス) JSON 指向のプロトコルと同様に、Base64 でエンコードされた ASN.1 DER オブジェクトが引き続き存在します。 ACME 「Let's Encrypt」から。 これらすべてのコーデックと BER/CER/DER のコーディング原則については、次の記事や書籍を参照するとよりよく理解できます。 ASN.1を簡単に言うと, ASN.1 — 異種システム間の通信、Olivier Dubuisson著, ASN.1 完了者: John Larmouth 教授.

BER は、バイナリのバイト指向 (セルラー通信で一般的な PER など、ビット指向) TLV 形式です。 各要素は次のようにエンコードされます: tag (Tag)、エンコードする要素のタイプ (整数、文字列、日付など)、長さ (Length) コンテンツとコンテンツ自体 (V値)。 BER では、オプションで、特別な不定の長さの値を設定し、End-Of-Octets メッセージを End-Of-Octets マークで終了することにより、長さの値を指定しないようにできます。 長さのエンコードに加えて、BER には次のようなデータ型のエンコード方法にも多くのばらつきがあります。

• INTEGER、OBJECT IDENTIFIER、BIT STRING、および要素の長さは正規化されない可能性があります (最小形式でエンコードされない)。
• BOOLEAN はゼロ以外のコンテンツに対して true です。
• ビット文字列には「余分な」ゼロ ビットが含まれる場合があります。
• ビット文字列、オクテット文字列、および日付/時刻を含むそれらのすべての派生文字列タイプは、可変長のチャンクに分割できますが、その長さは (デ) エンコード時に事前にはわかりません。
• UTCTime/GeneralizedTime には、タイム ゾーン オフセットと秒の「追加の」ゼロ端数を指定するさまざまな方法がある場合があります。
• DEFAULT SEQUENCE 値はエンコードされる場合とエンコードされない場合があります。
• オプションで、BIT STRING の最後のビットの名前付き値をエンコードしないことができます。
• SEQUENCE (OF)/SET (OF) には、任意の順序の要素を含めることができます。

上記のすべての理由により、元の形式と同一になるようにデータをエンコードすることが常に可能であるとは限りません。 したがって、ルールのサブセットが考案されました。 DER - 有効なエンコード方式を XNUMX つだけ厳密に規制します。これは、たとえば XNUMX ビットを変更すると署名やチェックサムが無効になる暗号化タスクにとって重要です。 DER には重大な欠点があります。エンコード時にすべての要素の長さを事前に知っておく必要があるため、データのストリーム直列化ができません。 CER コーデックにはこの欠点がなく、同様にデータの明確な表現が保証されます。 残念ながら (あるいは、さらに複雑なデコーダがないのが幸いでしょうか?)、普及しませんでした。 したがって、実際には、BER と DER で符号化されたデータが「混合」して使用されることになります。 CER と DER は両方とも BER のサブセットであるため、どの BER デコーダでもそれらを処理できます。

pyasn1 の問題

職場では、暗号化に関連した Python プログラムをたくさん作成しています。 そして、数年前には、無料ライブラリの選択肢は事実上ありませんでした。これらは、整数や構造体ヘッダーなどを単純にエンコード/デコードできる非常に低レベルのライブラリか、このライブラリのどちらかでした。 ピャスン1。 私たちはそれを数年間使用していましたが、最初は非常に満足していました。なぜなら、これにより、高レベルのオブジェクトと同じように ASN.1 構造を操作できるからです。たとえば、デコードされた X.509 証明書オブジェクトを使用すると、そのフィールドにアクセスできます。辞書インターフェイス: cert[“tbsCertificate”] ["serialNumber"] は、この証明書のシリアル番号を示します。 同様に、複雑なオブジェクトをリストや辞書として操作して「組み立て」、pyasn1.codec.der.encoder.encode 関数を呼び出すだけで、ドキュメントのシリアル化された表現を取得できます。

しかし、欠点、問題、限界も明らかになりました。 pyasn1 にはエラーがあり、残念ながら今でもエラーがあります。この記事の執筆時点では、pyasn1 の基本型の XNUMX つは 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 でシリアル化されたデータを「手動で」ウォークスルーするものでした。 しかし、たとえば、OCTET STRING バイト文字列は複数のチャンクの形式でエンコードされる可能性があるため、この方法で BER シリアル化されたデータを扱うことは不可能でした。

pyasn1 タスクのもう 1 つの欠点は、デコードされたオブジェクトからは、指定されたフィールドが SEQUENCE に存在するかどうかを理解できないことです。 たとえば、構造体に Field SEQUENCE OF Smth OPTIONAL フィールドが含まれる場合、受信データにそのフィールドがまったく存在しないか (OPTIONAL)、存在するが長さがゼロ (空のリスト) になる可能性があります。 一般に、これは決定できませんでした。 そして、これは受信したデータの正当性を厳密に検証するために必要です。 ある認証局が、ASN.XNUMX スキームの観点から「完全には」有効ではないデータを含む証明書を発行すると想像してください。 たとえば、認証局「TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı」は、ルート証明書の許容制限を超えています。 RFC 5280 対象コンポーネントの長さの制限 - スキームに従って正確にデコードすることはできません。 DER コーデックは、値が DEFAULT に等しいフィールドが送信中にエンコードされないことを要求します。そのようなドキュメントは実際に存在し、PyDERASN の最初のバージョンでは、そのような (DER の観点から見て) 無効な動作を意図的に許可していました。下位互換性。

もう 1 つの制限は、特定のオブジェクトが構造内でどのような形式 (BER/DER) でエンコードされているかを簡単に確認できないことです。 たとえば、CMS 標準では、メッセージは BER でエンコードされていると規定されていますが、暗号化署名が生成される signedAttrs フィールドは DER 内に存在する必要があります。 DER でデコードすると CMS 自体の処理に失敗しますが、BER でデコードすると signedAttrs がどのような形式であったかがわかりません。 その結果、TLVSeeker (pyasnXNUMX には類似物がありません) は、各 signedAttrs フィールドの場所を検索し、シリアル化された表現から個別に取り出して、DER でデコードする必要があります。

非常に頻繁に発生する DEFINED BY フィールドを自動的に処理する機能は、私たちにとって非常に望ましいものでした。 ASN.1 構造をデコードした後、構造フィールドで指定された OBJECT IDENTIFIER に基づいて選択されたスキームに従ってさらに処理する必要がある多くの ANY フィールドが残る場合があります。 Python コードでは、これは if を記述し、任意のフィールドのデコーダーを呼び出すことを意味します。

PyDERASNの登場

アトラスでは、問題を発見したり、使用している無料プログラムを改善したりした場合に、定期的にパッチをトップに送信します。 私たちは pyasn1 に対する改善を何度か提出しましたが、pyasn1 のコードは理解しやすいものではなく、互換性のない API の変更によって私たちが打ちのめされることもありました。 さらに、私たちは生成テストを使用してテストを書くことに慣れていますが、pyasn1 ではそうではありませんでした。

ある晴れた日、私はこれにはもう飽きたと判断し、__slot__、オフセット、美しく表示された BLOB を使用して独自のライブラリを作成してみました。 ASN.1 コーデックを作成するだけでは十分ではありません。すべての依存プロジェクトを ASN.1 コーデックに転送する必要があります。これらのコードは、ASN.1 構造での作業が満載の数十万行になります。 つまり、その要件の 100 つは、現在の pyasnXNUMX コードの翻訳の容易さです。 休暇をすべて費やして、このライブラリを作成し、すべてのプロジェクトをそこに転送しました。 テストではほぼ XNUMX% カバーされているため、ライブラリが完全に動作していたことを意味します。

PyDERASN も同様に、ほぼ 100% のテスト カバレッジを備えています。 優れたライブラリを使用した生成テストを使用します 仮説。 も実施されました ファジング py-afl- 私は 32 台の核マシンで食事をしています。 Python2 コードがほとんど残っていないという事実にもかかわらず、PyDERASN は依然としてそれとの互換性を維持しており、そのため、唯一の 6 依存症。 さらに、それはに対してテストされます ASN.1:2008 準拠テストスイート.

これを操作する原理は、高レベルの Python オブジェクトを操作する 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(serial, content) のようなあいまいな引数はありませんが、def func(serial: CertificateSerialNumber, content: 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) unsatisfiedbounds: 1 ⇐ 77 ⇐ 64 ASN .1 構造を記述する場合、間違いを犯す可能性があります。これにより、アプリケーションのデバッグや、相手のコード化されたドキュメントの問題の発見が容易になります。

PyDERASN の最初のバージョンは BER エンコードをサポートしていませんでした。 これはずっと後に登場しましたが、タイム ゾーンを使用した UTCTime/GeneralizedTime の処理を​​まだサポートしていません。 このプロジェクトは主に自由な時間を使って書かれているため、これは将来的に行われる予定です。

また、最初のバージョンでは DEFINED BY フィールドは使用できませんでした。 数か月後これ 機会が生じた 積極的に使用され始め、アプリケーションコードが大幅に削減されました。XNUMX回のデコード操作で、非常に深くまで分解された構造全体を取得することができました。 これを行うために、スキーマはどのフィールドが何を「定義」するかを指定します。 たとえば、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 構造の場合と同様に、フィールドは同時に複数のフィールドを「定義」できます。 定義されたフィールドは、いわゆるデコード パスによって識別されます。これは、すべての構造内の要素の正確な位置を指定します。

これらの定義をダイアグラムにすぐに追加したいとは限らず、またその機会が常にあるわけではありません。 OID と構造がサードパーティ プロジェクトでのみ知られている、アプリケーション固有のケースが存在する可能性があります。 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 内のシーケンス番号、CHOICE 値 (存在する場合)、人間が判読できる名前 INTEGER/ENUMERATED/BIT STRINGスキームによると、任意の基本型の値、スキームからの DEFAULT/OPTIONAL フラグ、オブジェクトが DEFINED BY として自動的にデコードされたことの兆候、およびどの OID が原因でこの問題が発生したか、人間が判読できる OID。

Pretty Printing システムは、別の手段を使用して視覚化される一連の PP オブジェクトを生成するように特別に設計されています。 スクリーンショットには、単純な色のテキストでレンダラーが表示されています。 JSON/HTML 形式のレンダラもあり、次のように ASN.1 ブラウザで強調表示して表示できます。 asn1js プロジェクト。

その他の図書館

これは目標ではありませんでしたが、PyDERASN は大きな成果を上げました もっと早く pyasn1よりも。 たとえば、メガバイト サイズの CRL ファイルのデコードには非常に時間がかかるため、中間データ ストレージ形式 (高速) を検討し、アプリケーション アーキテクチャを変更する必要があります。 pyasn1 は CRL をデコードします CACert.org 私のラップトップでは 20 分以上かかりますが、PyDERASN ではわずか 28 秒しかかかりません。 プロジェクトがあります asn1暗号、暗号構造の高速作業を目的としています。同じ CRL を (遅延ではなく完全に) 29 秒でデコードしますが、Python3 で実行するとほぼ 983 倍の RAM (498 MiB 対 3.5)、Python2 で実行すると 1677 倍 (488 MiB) 消費します。一方、pyasn1 は 4.3 倍も消費します (2093 対 488)。

先ほど述べた asn1crypto については検討しませんでした。なぜなら、このプロジェクトはまだ初期段階にあり、それについて聞いたことがなかったからです。 同じ GeneralizedTime が任意の形式を取っておらず、シリアル化中に 509 秒未満の部分が黙って削除されることがすぐにわかったため、私たちは彼の方向に目を向けません。 これは、X.XNUMX 証明書を使用する場合には許容されますが、一般的には機能しません。

現時点では、PyDERASN は私が知る限り最も厳密な無料の Python/Go DER デコーダーです。 私の愛するGoのencoding/asn1ライブラリ内 厳密なチェックではない OBJECT IDENTIFIER および UTCTime/GeneralizedTime 文字列。 場合によっては、厳密性が邪魔になることがあります (主に、誰も修正しない古いアプリケーションとの下位互換性が原因です)。 そのため、PyDERASN は問題を解決できます。 各種設定 弱体化チェック。

プロジェクトのコードは可能な限り単純になるように努めます。 ライブラリ全体が XNUMX つのファイルになります。 コードは、不必要なパフォーマンスの最適化や DRY コードを使用せず、理解しやすさを重視して書かれています。 すでに述べたように、UTCTime/GeneralizedTime 文字列、および REAL、RELATIVE OID、EXTERNAL、INSTANCE OF、EMBEDDED PDV、CHARACTER STRING データ型の完全な BER デコードはサポートしていません。 それ以外の場合は、個人的には Python で他のライブラリを使用する意味がありません。

私のすべてのプロジェクトのように、 ピゴスト, ゴーゴスト, NCCP, GoVPN、PyDERASNは完全に フリーソフトウェア、規約に基づいて配布されます LGPLv3+、無料でダウンロードできます。 使用例もございます ここで と PyGOST テスト.

セルゲイ・マトヴェエフ, サイファーパンクメンバー SPO財団, Python/Go 開発者、チーフスペシャリスト FSUE「STC「アトラス」」.

出所： habr.com