Giblets IPsec、TLS 1.3、GOST、Goに対して測定

こんにちは！私は、現代の機器をご紹介したいのIPsecのスタックESPv3とIKEv2のプロトコル。IPsecは、私には不当に多くの側面を迂回しているように思われ、ロシア語でのその作業、プロトコル、および機能の詳細な分析を見たことがありません。また、奇妙なことをします。IPsecESPv3とIKEv2（両方とも2005）を、2018年の最新のトレンディな最先端のTLS1.3と比較します。





なぜ私はIPsecにとても情熱を持っているのですか？おそらくネットワークを保護するための最も複雑なプロトコルスタックですか？結局のところ、複雑さは信頼性と安全性の主な敵です！まず、そのプロトコル、特にIKEv2について学ぶほど、多くの可能性がそこに投入されたことを理解し、「クラッチがクラッチを駆動する」という開発者の一般的なアプローチや「雷が発生するまで」深刻な問題の解決策とは対照的に、その思慮深さに感銘を受けます。第二に、IPsecプロトコルは暗号化の観点からよく考えられており、実際、古いESP / IKEv1でさえ、深刻な脆弱性がなかった唯一の産業用の大量使用プロトコルです。同じSSL（1995年）はバージョン1.3からのみきちんと考えられるようになりました。そして、IKEv1の巨大な複雑さのために多くの人々がIPsecを嫌います。これはv2にはありません。



理想的には、オペレーティングシステムの開発者が、IPsecとIPv6の実装と実装（コンピュータの可用性のため、NATがないため）で時間の速度が低下していなければ、SSL / TLSは原則として表示されるべきではありません。世界は完璧ではないことが判明しましたが、IPPE（少なくともスタックのSA / SP + ESP部分）は少なくともいくつかの広範なOSにあります（個人的には、サポートする開発者が不足しているためにIPsecを飲んだDragonFly BSDしか知りません）、また、一部の先進国のIPv6は、大多数の人々がすぐに利用できます。



IPsecは、プロトコル、API呼び出し、フレームワークのスタックであり、アプリケーションや管理者が通信中に必要なセキュリティを判断でき、ネットワークレベルで透過的に保証されます（IP秒urity）。1つのソケットのみのIPパケット（TCP接続など）と、ネットワーク全体間のトラフィックの両方について話すことができます。



トラフィックセキュリティとは、データの機密性、データの信頼性/整合性、および再生攻撃からの保護を確保することを意味します。ほとんどすべてのプロトコルと同様に、IPsecには、IPパケットを保護するトランスポート部分と、キーネゴシエーション、パラメーター、構成、およびパーティの認証に関連するハンドシェイク部分があります。



TLS 1.3：TCP接続のソケットごとのデータ保護のみを提供します。DTLSはデータグラムの保護を提供できますが（DTLS 1.3はまだ標準ではありません）、すべてのライブラリがこれをサポートしているわけではありません。

トランスポートプロトコル

IPsecトランスポートはIPプロトコルを使用します。

• AH（認証ヘッダー）。AHはデータの機密性を提供しないため、これ以上は説明しません。私が聞いた限りでは、暗号化の使用制限に関する1990年代の一部の国の法律に何らかの形で「我慢」するためだけに作成されました。暗号化は他のすべてに比べて非常に軽量であるため、それを犠牲にすることは意味がありません。しかし、ESPが言及されているほとんどすべての場所で、AHも意味されます。
• ESP（セキュリティペイロードのカプセル化）。ESPは時間の経過とともにわずかに進化し、現在はESPv3バージョンを使用しています。これは、多くの場合、下位互換性があり、以前のバージョンと同じです。

IPトラフィックは、トランスポート層によってのみ保護されます。また、1秒あたり数百万のパケットについて話すことができるため、事実上のESPは、オペレーティングシステムのカーネルレベルで、少なくともそのネットワークスタックに実装され、カーネルとユーザースペースの間でコストのかかるコンテキスト切り替えを行わないようにします（通常はTLSで発生します）。 、SSH、OpenVPNなど）。



AHとESPはIP層プロトコルであり、ネットワークであり、トランスポートではないことを強調します。なぜUDPではないのですか？チェックサムは冗長でCPUを消費し、暗号化はとにかく整合性を保証します。しかし、あなたのNATがESPについて何も知らない（そして彼が知らない）場合、これはすべて彼にとってはうまくいきません。後で彼らはNAT-Tクラッチを思いついた （NATトラバーサル）、IPsecトラフィックがポート4500でUDPパケットにラップされ、NATを通過できる場合、これは不要なオーバーヘッドであり、カーネル内のIPsecスタックを編集する必要があります。これは、これらの特別なUDPパケットをすでに理解し、ESPを抽出する必要があるためです。通常の処理。

SP、SA、SPIおよび最初のIPsec暗号化

カーネルは、IPパケットをどのように処理するかをどのように認識しますか。キーを使用して暗号化するか、着信ESPを復号化するか、またはIPパケットに触れずに通過させるか。これを行うために、カーネルにはセキュリティポリシー（SP）があります。これらはファイアウォールのようなルールです。それらに加えて、コアにはセキュリティアソシエーション（SA）が含まれています：暗号化操作（キー、カウンター、ウィンドウ再生など）を実行するためのコンテキスト。一般に、SPはIPsec固有でもSAでもありません。他のタスク/プロトコル（OSPFなど）に使用できます。



SP / SAは、特別なAPI（PF_KEYv2）を介して、またはいくつかのsetkeyユーティリティを介して手動で構成できます。たとえば、すべてのIPパケットが送信元であることをカーネルに通知する場合fc :: 321の123アドレスはESPを介して保護する必要があります。これは、コマンドラインから呼び出すことで簡単に実行できます。

$ echo "spdadd fc00::123 fc00::321 any -P out ipsec esp/transport//require;" | setkey -c

このコマンドの前に、pingが表示されました。

IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 0, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 1, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16

カーネルは暗号化する「何」をまだ知らないので、後でそれを見ることができません。SAを追加する必要があります。これは手動で行うこともでき、AES-GCM-16アルゴリズムのAEAD暗号化とランダムな160ビットキーの使いやすさを設定します。

echo "add fc00::123 fc00::321 esp 0xdeadbabe -E aes-gcm-16 0x0c09d1d90f804b0b4cef80e255e29c0894db1928 ;" | setkey -c

リモートホストで同じコマンドを実行すると（で-Pを指定することを忘れないでください）、次のように表示されます。

IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x1), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x2), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16

リクエストはESPによって暗号化されますが、返信は暗号化されません。ESPはデフォルトで「一方向」で動作するため、双方向通信の場合は、反対方向に別のSP / SAを追加する必要があります。この例の



0xdeadbabeは、セキュリティパラメータインデックス（SPI）です。これは、2つのIPアドレス間のESP「トンネル」の一意の識別子であり、カーネルは対応するSAコンテキストを見つけて、そこから復号化キーを取得できます。また、esp / transport // requireは、ESPをトランスポートモードで使用するための要件です（詳細は以下を参照）。

Giblets ESP

ESPパッケージは、次のように概略的に構成されています。

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|               Security Parameters Index (SPI)                 | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A
|                      Sequence Number                          | | u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t
~                       IV (variable)                           ~ | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e -----
|                    Payload Data  (variable)                   | | n   ^ E
~                                                               ~ | t   | n
|                                                               | | i   | c
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c   | r
|               |         TFC Padding * (optional, variable)    | | a   | y
+-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t   | p
|                         |        Padding (0-255 bytes)        | | e   | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d   | e
|                               |  Pad Length   | Next Header   | v     v d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------
~         Integrity Check Value-ICV   (variable)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• SPI -IPアドレス間のESPセッション/トンネル/接続の32ビットの一意の識別子。通常、{SrcIP、DstIP、SPI}はSAおよび暗号化コンテキストです。
• SeqNum — 32- . . , replay attack.
• payload — ESP, .
• TFC padding — (Traffic Flow Confidentiality), , - , . TFC , , payload , . , payload IP , . TFC - , .
• Padding — ESP payload 32- , . , ( CBC) . . .
• Pad Length — 8- Padding .
• Next Header — 8- IP payload. «no next header», ESP- — , . TFC — .
• ICV — Integrity Check Value, (MAC).

ペイロードから次のヘッダー までのパケットのすべての部分が暗号化されます。 MAC以外はすべて認証されます。 ICVの長さ、IV（初期化ベクトル）の存在は、使用される暗号化および認証モード/アルゴリズムによって異なります。



TLS 1.3：指定されたサイズへのオプションのデータのパディングはバージョン1.3でのみ登場しました。それ以外の点では、暗号化と認証は完全に似ています。 TLS 1.3は、AEADアルゴリズムのみを使用することを義務付けています。これは正しくて優れています。 ESPはAEADをサポートしていますが、より古風なソリューションの選択肢があります。タイプフィールドSPIまたはSeqNumいいえ、TCPはシーケンスと配信を保証するため、さらに、実際には、初期化ベクトルは明示的に送信されません。したがって、TLSレコードレイヤーパケットはわずかに短くなります。 DTLSには、SeqNumとメッセージフラグメンテーションデータがすでに含まれています。



32ビットのパケット番号は実際には短すぎる可能性があります。これはわずか40億以上のIPパケットであり、10Mpps以上の速度で数分で飛行できます。カウンターがオーバーフローするとどうなりますか？ゼロにリセットされます。ただし、これは、SPI + SeqNumの値が繰り返され始め、以前にインターセプトされたESPパケットを使用して攻撃を再生できることを意味します。この問題を解決するために、ESNが発明されました（拡張シーケンス番号）。これは64ビットのカウンターですが、その「下位」の32ビットのみがSeqNumフィールドに転送され、上位の32ビットがメモリに保存されます。ESNの全額が認証されます。したがって、当事者はESNの使用について事前に合意する義務があります。

ESP暗号化

たとえば、AES-GCM-16を使用している場合、ESPパケットの暗号化/認証はどの程度正確に行われますか？ ESPを操作するには、ペイロードの先頭にある64ビットの初期化ベクトルを使用します。また、キーマテリアルの一部として32ビットソルトを使用しています。setkeyの例では、128ビットのキーではなく、128 +32ビットのキーを指定しました。キーが再利用され、IVが値を繰り返すことができる不良な疑似ランダム番号ジェネレーター（PRNG）で満たされている場合があります。ソルトは、傍受されたパケットの復号化につながる可能性のあるこの最も危険なケースから保護するように設計されています。 AES-128-GCM-16-ESPモードでのESP暗号化/認証自体は次のとおりです。

AES-GCM(
    key             = 128-bit key,
    plaintext       = 64-bit IV || payload || TFC || pad || padLen || NH,
    nonce           = 32-bit salt || IV,
    associated-data = SPI || {ESN  SeqNum},
) -> encrypted-payload || 128-bit ICV

ESP = SPI || SeqNum || IV || encrypted-payload || ICV

ロシアのGOSTアルゴリズム（MagmaまたはGrasshopper暗号）の場合、入力データは類似しています。両方の暗号はMGMモードで使用され（GCMの改良版と言えます）、HMAC-Stribog-256を使用して通常のESPTREEキーマテリアルローテーションが適用されます。これにより、キーの負荷が軽減されます。主にIPsecのコンテキストでは、これはサイドチャネルを介した攻撃面を減らすほど、使用時間を増やすことではありません。たとえば、キーメッシュ（一定のキーローテーションの同様のテクノロジ）により、64ビットブロックサイズのGOST28147-89ブロック暗号はSWEET32攻撃に対して無防備であることが判明しました。



安全性の観点から、AEADアルゴリズムを使用したESPについての不満はありません。ただし、AEADアルゴリズムの場合、IVは単なる64ビットのカウンターであり、パケット内のスペースを浪費する各パケットとともに明示的に渡されます。SeqNumは短すぎ、ESNは完全には送信されませんが、IVとして完全に適合します。非AEADアルゴリズムの場合、IVはすでに必要であり、予測できない値を持っている可能性がありますが、決してカウンターではありません。これはレガシーであり、パッケージ内の貴重なスペースを食い尽くし、重量はここでの信頼性に影響を与えません。







AEADのIVが128ビットからの値を持つことができる場合、192ビットのナンスでXSalsa20 / XChaCha20のようなアルゴリズムを使用することが可能であり、そのうちの128ビットは起動時に疑似ランダムに生成され、残りの64ビットはカウンターに使用できます..。これは、カウンター状態を失ったが、既存のキーを引き続き使用したいシステムにとっては命の恩人になる可能性があります。



TLS 1.3：XORは、メッセージカウンターとキーで生成された初期化ベクトルの間のナンスとして使用されます。メーターもIVも明示的に送信されないため、TLS1.3はもう少しコンパクトです。ESPが非AEADアルゴリズムを使用する場合、予測できないIVの生成が必要になる可能性があり、これは著しくCPUに負荷をかける可能性があります。

トンネルモードとトランスポートモード

パッケージ のペイロードには何が含まれていますか？これは、ESPがトランスポートモードで動作しているかトンネルモードで動作しているかによって異なります。トランスポートモードは、送信されたIPパケットのペイロードをこのペイロードのESPに置き換えます。つまり、次のようになりました。

---------------------------------------
| orig IP hdr |[ext hdrs]| TCP | Data |
---------------------------------------

なりました：

---------------------------------------------------------
| orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
                             |<--- encryption ---->|
                         |<---- authenticity ----->|

トンネルモードでは、IPパケット全体がESPで完全にラップされ、通常は新しいヘッダーとSrcIP / DstIPアドレスを使用して新しいIPパケットが形成されます。このモードは、ネットワーク間でパケットをトンネリングするために使用されます。

----------------------------------------------------------
| new* |new ext|   | orig*|orig ext|   |    | ESP   | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
----------------------------------------------------------
                   |<--------- encryption --------->|
               |<---------- authenticity ---------->|

例えば、貫通はsetkey私の間のすべてのパケットのように指定することができ、AC :: / 64：2001および2001：DC :: / 64ネットワークがアドレスとトンネルの2つのエンドポイントを介して暗号化された渡す必要2001 :: 123、2001 :: 321 ..。

spdadd 2001:ac::/64 2001:dc::/64 any -P out ipsec esp/tunnel/2001::123-2001::321/require ;
spdadd 2001:dc::/64 2001:ac::/64 any -P in  ipsec esp/tunnel/2001::321-2001::123/require ;

トランスポートモードは、多くの場合、ホスト間接続と呼ばれます。2つのエンドポイント間ですでに機能しているトンネリングにGREまたはIPv * -over-IPv *プロトコルが使用されている場合、この場合、IPsecレベルでトンネリングモードを使用することは意味がありません。ただし、トランスポートモードはIPヘッダーを認証しません。原則として、これは重要でも重要でもありませんが、拡張IPv6ヘッダーまたはパケットのフローラベルが変更されていないことを確認する場合は、2つのホスト間であっても、オーバーヘッドを犠牲にしてトンネルモードを使用する必要があります。

ISAKMP

コンピューターを再起動すると、すべてのカウンター値を持つSAがメモリから消え、古いSP / SAコマンドを手で再度ロードするとどうなりますか？まず、IVに一致するパケットを復号化できます。これは、暗号パッドを2回使用するのと同じだからです。次に、SPI / salt / ESN / SeqNumが一致するため、以前にインターセプトされたすべてのパケットが有効に認証され、それらを再生できます。このようなセットキーSAを再利用することは、セキュリティにとって悲惨です。第3に、特にESNが使用されていない場合（たとえば、この記事の執筆時点でFreeBSDでは、まだサポートされていません）、長いSA操作では、カウンターが「使い果たされている」ことに気付かない場合があります。



これはすべて、ESPキーを定期的に変更する必要があることを意味します。また、暗号化アルゴリズム、ESN、TFC、トランスポート/トンネルモード、SPI値の存在についてもネゴシエートします。事実上、これにはISAKMPプロトコル（インターネットセキュリティアソシエーションおよびキー管理プロトコル）が使用されます。ただし、OTR / PGP / OMEMO認証暗号化を使用してIMを簡単にねじ込み、シェルスクリプトのsetkeyコマンドをサーバーに送信するだけで、キーは/ dev / urandomを読み取ることで生成されます。それがどのように合意されたかは、カーネルにとって重要ではありません。 OpenVPNの場合と同様に、証明書を使用したX.509認証とキーネゴシエーションは通常TLSを介して行われ、VPNトランスポートプロトコル自体はすでに独自のものです。



「純粋な」形式では、暗号化が含まれていないため、ISAKMPは使用されません。対話者を認証し、主要な資料を生成するために、ISAKMPを内部にカプセル化するサードパーティのプロトコルが使用されます。知っている：

• KINK -キーのKerberos対応のインターネット交渉第三は、Kerberos KDCを信頼し、認証との交渉のために使用されています。ウィキペディアからの説明に加えて、私はKINKについてこれ以上何も知らず、ライブで見たことがありません。
• IKE（v1）-インターネットキー交換。1998年に作成されましたが、おそらくまだ最も人気のあるプロトコルです。
• IKEv2は、2005年のIKEの2番目のバージョンです。これについては後で説明します。

IKEプロトコルは、さまざまなペイロードタイプが多数あるため、非常に拡張性があります。 IKEv1には、1つのトンネルだけを機能させるように構成するための多数のオプションがあります。共通のペイロードを持つISAKMPとIKEv1の全体を説明する12以上のRFC。恐ろしい複雑さ。さらに、絶対に確実でない構成を簡単に台無しにする機能と、IKEv1がほぼ完全に構成ファイルをコピーした場合にのみ機能することが保証されているという、よく知られている、部分的には当然の神話です。



幸いなことに、IKEv2が登場しました。1つの便利なRFC（ほとんどの機能）、パラメーターをネゴシエートするための大幅に簡素化されたプロトコル、したがってその構成です。原則として、IKEv1よりもハンドシェイクおよびキー合意プロセス全体のラウンドトリップが少なくなります。したがって、IKEv1には意味がなくなったため、彼だけが考慮されます（ただし、すでに実行中および動作中のインスタンスは動作しているため、置き換えることはほとんど価値がありません）。IKEv2は、IKEv1とは異なり、ESPとまったく同様のアルゴリズムとアプローチを使用して、独自のメッセージを暗号化します。また、EAP認証と、各当事者がさまざまな方法で認証する機能も導入されました（たとえば、クライアントはPSKを使用し、X.509サーバーは証明書を使用します）。

IKEデーモン

      +-------------+
      |  |
      +-------------+
       |           |
       |           |
       |           |      /userspace
=====[PF_KEY]====[PF_INET]====================
       |           |                    
+-----------+   +-------------+
| |   |TCP/IP,      |
|  SA  SP  |---| IPsec|
+-----------+   +-------------+
                     |
                 +-----------+
                 |    |
                 |  |
                 +-----------+

IPsecスタックのこの部分は、通常はユーザースペースですでに実行されています。まず、これらは負荷の高いデーモンではありません。少なくとも1日に1回は相互に通信でき、最初のハンドシェイクにはUDPを介した数回のラウンドトリップが必要です。第二に、ISAKMP / IKE機能の数は、完全なSA / SP / ESP実装の数百倍のコードがあるようなものです。 ISAKMPデーモンはたくさんあります：strongSwan（IKEv1 / v2）（およびOpenswan、Libreswan）、isakmpd（IKEv1）、OpenIKED（IKEv2）、racoon（IKEv1）、racoon2（IKEv1 / v2、KINK）など。



注：「デーモン」（デーモン）を記述して話すのは正しいです）、私がフィクションの翻訳で見たように。しかし、技術的なロシア語圏では、「悪魔」はすでに根付いています。



TLS 1.3：一般に、TLSスタック全体は、個々のアプリケーションで機能し、キーマテリアルを独自のメモリに格納するライブラリ関数です。すべての暗号化は、ユーザースペースへの切り替えで行われます。これは大きなオーバーヘッドです。ただし、IPsecと同様に、トランスポート部分が完全にカーネルで処理され、ハンドシェイクがユーザースペースで行われる場合、少なくともFreeBSDとLinuxにはすでにTLSのカーネルオフロード実装があります。



IKEv2はUDP上で実行され、デフォルトではポート500（isakmpサービス）。デーモンは、安全なチャネルの作成、相互の認証、ESP SA / SPのネゴシエーション/作成/削除、キーの更新、ハートビートの実行（Dead Peer Detection（DPD））などを行います。デーモン間のすべての通信は、要求/応答メッセージのペアの交換の形で行われます。すべての要求に答える必要があります。これはUDPなので、パケットが欠落している場合はどうすればよいですか？あなたの州ではこれを考慮に入れ、応答が受信されていないタイムアウト後に要求を再送信し、繰り返される要求への応答を再送信し、繰り返される応答を無視します。パケットは混沌とした順序で到着する可能性があり、予期せず消える可能性があります。IKEv2標準では多くのことが考慮されており、さまざまなレース条件下での動作方法が説明されています。



TLS 1.3：TLSのTCPの性質により、メッセージの順序と配信が処理されます。ただし、TCPはOSカーネルでかなりのリソースを消費し、（UDPとは異なり）膨大な数のTCPセッションが問題になる可能性があります。ただし、DTLSでは、IKEの場合と同じようにすべての同様の問題が発生し、さらに断片化されたメッセージの処理を伴う痔核が追加されます。 UDPのエンドポイントのIPアドレスを変更することは問題ではありません。 IKE接続は、原則として非常に長寿命であるため（IKE状態は小さく、ユーザースペースデーモンのメモリにのみ保存されます）、ハンドシェイクの必要性は少なくなりますが、TLSでは、TCP接続を失った後、それを行う必要があります（ただし、状態がない場合はセッションを継続する高速化された方法もあります）たとえば、プログラムを再起動したときに失われます）。 IKEデーモンは（原則として）システム全体のデーモンであるため、一部のアプリケーションがそれと安全に通信したい場合すでにIKE接続を持っている人と一緒にいる場合、その人はすぐにそれを使用するか、デーモンが1回のラウンドトリップでアプリケーション用の追加のESPSAを作成します。

Giblets IKE

デーモンの最初の交換（要求-応答）はIKE_SA_INITになります。これにより、さらに安全な通信のためにIKESAが作成されます。ESP SAはカーネルに「格納」され、IKESAはユーザースペースデーモンにあることに注意してください。次に、当事者が認証されるIKE_AUTH交換が行われます。同じ交換で、ESP SAに使用される子SA（子SA）が作成されます。一般に、これら2つの交換は、当事者を認証し、キーを使用してESP SAパラメーターをネゴシエートし、コンピューター間で暗号化されたESPトラフィックを駆動するのに十分です。この場合、動作中のIKESAがデーモン間に長時間残ります。さらに、いつでも、CREATE_CHILD_SA交換を行って、より多くの子SAを作成したり、INFORMATIONALを作成したりできます。交換（さまざまな目的）。



すべてのIKEv2メッセージヘッダーの構造は次のとおりです。

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload |    Version    | Exchange Type |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• SPIi -64ビットIKESAイニシエーターSPI。IKEセッションの開始者によってランダムに生成された識別子。
• SPIr -64ビットIKESAレスポンダーSPI。同様ですが、レスポンダー側からのSPIのみです。イニシエーターからの最初のメッセージでは、このフィールドはゼロバイトで埋められています。
• NP -8ビットの次のペイロード。ヘッダーに続くペイロードの識別子。
• バージョン-IKEプロトコルの8ビットバージョン。
• ExchType - IKE交換の8ビットタイプ：IKE_SA_INIT、IKE_AUTH、CREATE_CHILD_SA、またはINFORMATIONAL。
• Flags — 8- . .
• MsgID — 32- . , , replay-. — request/response MsgID. , .
• Len — 32- ( + ).

SPIi + SPIrは128ビットです。 ESPに32ビットしかないのに、なぜそんなに多いのでしょうか。まず、それらは一致しませんが、疑似ランダムに生成されるため、衝突を回避するには片側に64ビットで十分です。次に、ESPもIPアドレスに関連付けられていますが、IKEセッションは通常は関連付けられていません。当事者は、IPアドレス（モバイルクライアント）を簡単に変更して、通信を継続できます。



TLS 1.3：IPアドレスを変更すると、接続が切断されます。 iPSKを使用している場合でも、非対称暗号化のリソースを節約するために再ハンドシェイクを行う必要があります。これは、1.5ラウンドトリップとTCP接続を確立するためのラウンドトリップです。すでに確立されているIKE接続（アドレスにバインドされていない）での新しいIPアドレスでの子ESP SAの作成には、1回のラウンドトリップしかかかりません（+古いものを削除するためのラウンドトリップですが、これは新しい動作中のESP SAのバックグラウンドですでに発生します）。



IKEヘッダーの後には、1つ以上のペイロードが続きます。各ペイロードには、一般的なフォーマットヘッダーと、そのタイプに固有のコンテンツがあります。コンテンツは32ビットに揃えられています。すべてに共通のヘッダー：

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Next Payload — 8- . payload- . payload. payload IKE . Encrypted Payload, payload- NP ( payload IKE ), payload- .
• C — «» payload. IKEv2 payload , IKE . payload . IKE vendor-specific , .
• Len — 16- payload ( + ).

したがって、IKEメッセージは、チェーンでリンクされたIKEヘッダーとペイロードで構成されます。デーモンは、重要ではない未知のペイロードを無視できます。Nonceタイプ（ヘッダーの後）のペイロードコンテンツは、固定サイズではなく、単なるランダムなデータセットです。しかし、はるかに複雑な構造もあります。IKE標準では、ペイロードタイプの短い指定が受け入れられます（たとえば、ナンスメッセージの場合はN *、「*」は「i」（イニシエーター）または「r」（レスポンダー）のいずれかです）。

シグマ

暗号化の観点から、IKEv1 / IKEv2は、STS、ISO / IEC IS 9798-3、および認証済みキー交換プロトコルのSIGMA（SIGn-and-MAc）クラスに属しています。これらは非常によく研究され、数学的に検証された（SIGMA）ソリューションです。私の「P2PF2FE2EE IM in one night」の記事では、SIGMA-Iプロトコルの動作原理と実装についてすでに説明しました。IKEv2は完全に似ています。ハンドシェイクプロトコルのセキュリティについて議論するとき、私たちは何を期待していますか？

• 送信されたメッセージの機密性。
• 送信されたメッセージの信頼性と整合性-それらの変更を検出する必要があります。
• リプレイ攻撃からの保護-メッセージの損失またはリプレイの事実を検出する必要があります。
• ;
  
  perfect forward secrecy (PFS) — PSK ( IKE ESP SA). ;
  
  / ( ) IKE . / ( ) ;
  
  , , . .
  
  

そのような後のIKE_SA_INIT交換、デーモンが互いのアドレスを有する、SPII + SPIR IKEセッションの値、SAは（IKEの場合、これらは、鍵合意（あるアルゴリズムをネゴシエートDH）、メッセージの暗号化/認証（ENCR）、鍵生成（PRF）アルゴリズム）反対側の公開鍵（DH）。これは、状態をメモリに保存してキー合意（Diffie-Hellman、GOST R 34.10-VKO、curve25519など）を実行し、後続のIKEメッセージのペイロードを暗号化するための対称キーを生成するのに十分です。



TLS 1.3：ハンドシェイクメッセージの形式は非常に異なり、多くのレガシーがありますが、基本的に目立つものはありません。nonceの代わりにランダムフィールドが使用されます。ペイロードの代わりに、多数の拡張機能。複雑なSA提案構造の代わりに、よりコンパクトでシンプルな暗号スイート識別子が使用されます。私の意見では、SA提案の柔軟性は過度ですが、IKEv2ではこれはまだ問題ではなく、ciphersuiteと同様の値が構成ファイルに書き込まれます。TLS1.3バージョンでのみDH交換が必須になります。

IKEキー素材

後IKE_SA_INIT、SKEYSEEDがされて生成されました：

SKEYSEED = PRF（Ni [：8] || Nr [：8]、DH-KEY）

PRFアルゴリズムはIKESAで選択されています。たとえば、GOST IKEv2の場合、これはHMAC-Stribog-512関数です。 PRFキーは、各ナンスからの64ビットチャンクです。



ナンスはオープンに送信されるため、軽薄に見えます。つまり、このPRFのキーは、トラフィックを傍受したすべての人に知られています。ただし、ここではPRFは、DHの計算結果からキーを生成するためにのみ使用されます。これは攻撃者にはすでに知られていません。 DH関数の結果は、巨大で不均一なエントロピー値になる可能性があり、楕円曲線上の点になる可能性があります。これはすべて、短い高エントロピー対称キーとして使用することはできません。したがって、DH-KEY（これはSKEYSEEDです）からエントロピーを抽出してから展開する必要があります（展開）必要な数のキーに拡張します。

PRF+(SKEYSEED, Ni || Nr || SPIi || SPIr) ->
    SK_d || SK_ai || SK_ar || SK_ei || SK_er || SK_pi || SK_pr

PRF+(K,S) = T1 || T2 || T3 || T4 || ...
T1 = PRF(K,       S || 0x01)
T2 = PRF(K, T1 || S || 0x02)
T3 = PRF(K, T2 || S || 0x03)
T4 = PRF(K, T3 || S || 0x04)

これはすべて、HKDF関数と同様に、抽出/展開ステージを使用した従来のキー導出操作です。しかし、HKDFがハッシュ関数の使用を想定している場合、このPRF / PRF +構造は、対称暗号で簡単に使用できます-一般的なAES-GCM + AES-XCBC-PRFの場合、ハッシュ関数はどこにも使用されませんが、少数です使用されるプリミティブは常に良好です。



次のキーが生成されます。

• 子ESPSAのキーを生成するためのSK_dキー。
• IKEメッセージ認証用のSK_a [ir]キー。AEADアルゴリズム（AES-GCM、Grasshopper / Magma-MGM、ChaCha20-Poly1305など）が合意されている場合、生成されない/使用されません。
• SK_e[ir] IKE .
• SK_p[ir] AUTH.

TLS 1.3：はるかに複雑なキースケジューリングがあります。エントロピーは、個々のフィールドではなく、ハンドシェイクメッセージ全体から一度に絞り出されます。生成された拡張シーケンスは、いくつかのキーにカットされるだけでなく（+必要に応じてソルト）、これらのキーまたは生成されたIVの使用状況ごとにラベル（ラベル）を使用したHMAC変換も伴います。生成されたあらゆる種類の値にテキストラベル/アプリケーション/コンテキストを使用することは、現代の優れた慣行であり、必要かどうか疑問に思うよりも常に行う方が簡単です。出くわすすべてのものをハッシュすることも、「悪化することはない」という非常に良い習慣です。ただし、これはIKEv2のセキュリティが悪いことを意味するものではなく、ラベルがないことが攻撃者の手に渡る可能性がある、少なくともリモートで理論的な状況を簡単に思い付くことができるという意味でもありません。IKEv2では、アプローチは最小限ですが、TLS 1.3では、「オーバーライドする方が良い」（以前のバージョンのプロトコルで実行された妨害または問題の数が多いため）。 IKEv2は、実績のあるアプローチとプリミティブを引き続き使用し、必要なすべてを認証し、転送されたすべてのエントロピーを圧縮/考慮し、各サイドとタスクに異なるキーを使用します。

IKE_AUTH

次に、IKE_AUTH交換が実行され、両方の当事者が認証され、ESPSAがネゴシエートされます。

    SK{IDi, [CERT, ...], [CERTREQ], [IDr], AUTH, SAi2, TSi, TSr} -->
<-- SK{IDr, [CERT, ...],                   AUTH, SAr2, TSi, TSr}

• IKEメッセージには、他のすべてを含む暗号化（SK）ペイロードが含まれています。
• イニシエーターは、そのID（IDi）、オーセンティケーター（AUTH）、ESPのSAオファー（SAi2）、およびイニシエーター/レスポンダーのペア、いわゆるトラフィックセレクター（TS *）を提供します。オプションで、期待されるレスポンダーIDを送信することもできます。これは、TLSからの一種のSNIアナログと見なすことができます。
• 応答として、レスポンダーのID、ネゴシエートされたESP SAプロポーザル、確認済みのトラフィックセレクター、およびオーセンティケーターを受け取ります。
• その後、両方の当事者がお互いを認証済みと見なし、ESP SA、このESPに属する必要のあるトラフィックについて合意し、SAおよび場合によってはSPを作成するコマンドをカーネルにすでに発行できます（SPをまったく処理しないデーモンがあります）。

これらのペイロードについて詳しく説明します。

• ID-パーティ識別子。識別タイプとそれに固有のデータが含まれています。パーティは、IPv4 / IPv6アドレス、FQDN（完全修飾ドメイン名、文字列のみ、最も一般的な方法）、RFC822電子メールアドレス、ASN.1 DER識別名（X.509証明書を使用する場合の最も一般的な方法）または一般名など、さまざまな方法で識別できます。ベンダー固有だけでなく。
• AUTH — . PRF ( MAC-), (pre-shared key (PSK)), . (TBS*):
  
  
  
  

  TBSi = Msg0 || Nr || PRF(SK_pi, IDi)
  TBSr = Msg1 || Ni || PRF(SK_pr, IDr)
  

  
  
  (Msg0), nonce (Nr), (IDi), «» . , SK_pi ( ). «».
  
  
  
  / . . ( Ni Nr), . , , .
  
  
  
  , . ( ), . , - . round-trip-. SIGMA- , IKEv2, ESP SA, . , , . SIGMA MAC c ( SK_*). IKEv2 PRF, . , PRF(ID*) , brute-force ( ) .
  
  
  
  PSK, :
  
  
  
  

  AUTHi = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSi)
  AUTHr = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSr)
  

  
  
  PRF(PSK) PSK ? PSK PRF . PSK , /. PRF() «» . PRF(PSK) PSK PSK , ( Argon2, Balloon ).
  
  
• SA*2 — SA , ESP .
• TS* — . : IPv4/IPv6 , IP (), / (), / . :
  
  
  
  

  TSi = ((proto=17, port=100, fc::123 - fc::123),
         (proto=17, port=200, fc::123 - fc::123))
  TSr = ((proto=17, port=300, :: - ffff:..:ffff),
         (proto=17, port=400, :: - ffff:..:ffff))
  

  
  
  , UDP ( = 17), 100- 200- fc::123 , UDP 300 400. , IP . , , IP , ( , ICMP ). , .
  
  
  
  UDP . , , , 100 300-, ESP SA .
  
  
  
  応答側は、確認済みのセレクターの選択を送信します。セレクターは、一致するか、選択範囲が狭くなる可能性があります。

これらのペイロードはすべて、最初のメッセージ交換後にIKESAによって生成されたキーで暗号化されます。送信された当事者の識別子、その証明書、その他の個人情報を公開するために暗号化が必要です。ただし、アクティブな攻撃者は、最初のIKE_SA_INIT交換にウェッジしてこの情報を確認できますが、セッションを続行することはできなくなります。



TLS 1.3：

• application ( ServerHello ||… || Finished, , , ), (Client Finished). IKEv2 ESP SA round-trip-, TCP/SCTP handshake.
• , (IDr ), SNI, ClientHello . IKEv2 . ESNI, , DNS, DPI.
• IKEv2 , «»/«» ( ), PSK, , EAP. TLS 1.3 X.509 . TLS 1.3 X.509 . RFC TLS 1.3 «» . IKEv2 / .
• TLS 1.3 , , application ClientHello (EarlyData), application Client Finished . TLS 1.3 EarlyData .
• TLS (session resumption), iPSK , , . IKEv2 , RFC 5723 . IKE , , ( TCP/SCTP/whatever ) IP .
• TLS . IKEv2 IKE SA ESP SA . , () high-grade , . , , , . - ChaCha20-Poly1305, AES-256-GCM-16, -MGM . IKE SA ESP - NIST-.

AEAD暗号を 使用したSKペイロードの暗号化はトリッキーではなく、たとえばAES-GCMの場合のESPと完全に似ています（AES-GCM-ESPと同様に、塩は主要な材料の一部です）。

AES-GCM(
    key             = SK_*e,
    plaintext       = 64-bit IV || payloads || pad || 8-bit padLen,
    nonce           = 32-bit salt || IV,
    associated-data = IKEHdr || unencrypted payloads
) -> ciphertext

EDSによる認証

署名とX.509証明書で認証したい場合はどうなりますか？このため、既にIKE_SA_INIT、CERTREQのペイロードを送信することができるの形で証明書を提供するために、反対側を要求する、CERTのペイロードを。CERTおよびCERTREQには、証明書フォーマットIDとフォーマット固有のコンテンツが含まれています。通常、証明書はASN.1 DERとして、または証明書のSHA1ハッシュ+ダウンロード元のURLとして提示できます。 UDPのサイズはMTUによって制限されており、証明書のサイズははるかに大きくなる可能性があるため、ここではハッシュ+ URLオプションが有効です（ただし、クラッチと見なすことができます）。



IKEv2 RFCだけで、DERでエンコードされたX.509証明書とSHA1 + URLに加えて、PKCS＃7ラップされたX.509証明書、PGP証明書、DNS署名付きキー、SPKI証明書、X.509属性証明書、生の公開キーがリストされます。最も一般的なユースケースTLSと同じ方法でIPsecを使用する場合、つまりX.509証明書と匿名クライアントによって認証されたサーバーの場合、IKEv2ではいずれかの当事者を認証しない方法はありません。しかし、RFC 5386は、「クライアント」が裸の公開鍵を使用でき、サーバーがそれを匿名として扱うことができる、Better-Than-Nothing-Securityアプローチについて説明しています。



さらに、EAP認証が標準でサポートされており、IKE_AUTHにラウンドトリップが追加されています。両替。EAPは、パーティが認証されているかどうかを判断できるだけでなく、IKEv2が考慮して使用するキーを生成することもできます。EAPがどのように機能するかを示す図のみを示します。

                 SAi1, KEi, Ni  -->
                                <--  SAr1, KEr, Nr
SK{IDi, [IDr], SAi2, TSi, TSr}  -->
                                <--  SK{IDr, AUTH, EAP}
                       SK{EAP}  -->
                                <--  SK{EAP(success)}
                      SK{AUTH}  -->
                                <--  SK{AUTH, SAr2, TSi, TSr}

TLS 1.3：その中で、署名（またはFinishedメッセージのMAC ）は、ハンドシェイクに参加したすべての表示されたメッセージのハッシュの上に配置されます。また、シンプルで信頼性の高い優れたアプローチ。さまざまな認証方法はありません。しかし、ロシアのSESPAKEやOPAQUEなど、強力なAuthenticated Password Key Agreement（PAKE）プロトコルが必要です。

ESPSAの主要資料とその更新

そのため、認証を検証し、キー合意が正しいことを検証し、ESPSAとトラフィックセレクターをネゴシエートしました。ESPの対称キーを生成することは残っており、必要なSA / SPをカーネルにインストールできます。

PRF +（SK_d、Ni || Nr）-> KEYMAT0 || KEYMAT1

双方向通信には2つのESPSAが必要であるため、IKEv2は一度に2つの主要なマテリアルを生成し、それらはすでに対応するSAのコアに直接送信されています。マテリアルの長さは、使用するESPアルゴリズムによって異なります（たとえば、AES-GCM-ESPでは、キーに加えて、32ビットのソルトも必要です）。SPI値は、ESPSAプロポーザルの各当事者によって指定されたSPI値です。



たとえば、すべての希望を単一のTSi / TSrペアで指定できるわけではないため、複数のESP SA / SPについて合意する必要がある場合はどうなりますか？このために、IKE_AUTHの後いつでも発生するCREATE_CHILD_SA交換が使用されます。子SAの作成は、次の交換で行われます。

    SK {SA、Ni、[KEi]、TSi、TSr}->
<-SK {SA、Nr、[KEr]、TSi、TSr}

SAオファーが行われ、ナンス、トラフィックセレクターが送信されます。すべてが以前と同じです。キーマテリアルは、これらの新しいナンスを使用してすでに生成されています。オプションで、キー交換ペイロードを使用できます。これにより、エントロピーが追加され、当事者はさらに非対称の暗号化を使用するようになります。PFSプロパティを常に監視する必要がある場合があります（OTRプロトコルでは、エフェメラルDHキーが各メッセージとともに送信されます）。この場合の重要な資料は次のようになります。

PRF +（SK_d、DH-KEY || Ni || Nr）-> KEYMAT0 || KEYMAT1

接続のIKESAを更新したい場合はどうなりますか？次のCREATE_CHILD_SA交換を行います。

    SK {SA、Ni、KEi}->
<-SK {SA、Nr、KEr}

SAにはすでにIKESAの提案が含まれており、新しいSKEYSEEDが開発されます。

PRF（SK_d_old、DH-KEY || Ni || Nr）-> SKEYSEED

ESP SAキーは、新しいESP SA（別のSPIを使用）を作成して古いものを削除するか、特別な通知（以下でそれについて）を送信することによって更新されます。新しいESPSAを使用するようにトラフィックを切り替えると、透過的で損失がなくなります。短期間、当事者は2つのアクティブなESP SAを持ち、通信チャネルでまだ転送中のトラフィックを処理できるようになります。



ESP SAの削除は、削除するSPIをリストする後続のINFORMATIONAL交換でDELETEペイロードを送信することによって行われます。すべてのESPSAはペアで存在するため（双方向通信の場合）、各サイドは送信トラフィックを担当するESPSAにのみSPI値を送信します。それに応じて、着信トラフィックのSPI ESPSA値を受信します。

    SK {D（SPIi）}->
<-SK {D（SPIr）}

IKE SAの削除もDELETEを介して行われますが、IKE SPIを使用し、空の認証済み応答を受け入れます。

    SK {D}->
<-SK {}

TLS 1.3：KeyUpdateメッセージを介してキーを回転させるメカニズムがありますが、エントロピーを追加したり、DHを実行したりする可能性はありません。 TLSは明らかに、非常に長寿命の接続用に設計されていません。最良の場合、セッションを中断して続行/ハンドシェイクを使用してiPSK-ECDHEで新しいセッションを作成することしかできません。



IKEv1には、個別のIKEキー更新手順と、再認証用の個別の手順の両方があります。 IKEv2には再認証はありません。これを行うには、新しいIKE SAを最初から作成し、古いものをDELETEで削除します。



TLS 1.3：ハンドシェイク後の任意の時点で、ハンドシェイク後のクライアント認証機能を備えています（終了）両側からのメッセージ）、サーバーはX.509証明書を使用してクライアント認証の要求を送信できます。たとえば、サイトをさまよっているクライアントが、自分の個人アカウントのページにアクセスしました。IKEv2では、これは不可能です。認証は、ハンドシェイク時にのみ実行されます。

通知

では、トンネル/トランスポートモードはどのようにネゴシエートされますか、TFC？このために、「通知」NOTIFY（N）のペイロードが要求に追加されます。 IKEv2 RFCだけでも、数十種類の通知があります。アラートは、エラー、オファーのSAネゴシエーションの問題、トラフィックセレクターなど



を通知するために使用されます。ネゴシエートされたESP SAでトランスポートモードを使用する希望を通知するために、N（USE_TRANSPORT_MODE）通知がイニシエーターとレスポンダーの両方によって追加され、モードネゴシエーションを確認します。N（ESP_TFC_PADDING_NOT_SUPPORTED）アラートは、TFCがサポートされていないことを示します。また、N（HTTP_CERT_LOOKUP_SUPPORTED）は、URLからの証明書のダウンロードがサポートされていることを示します。



新しいESPSAを作成せずにESPSAキーを更新する機能は、子ESP SAを作成する手順と似ていますが、イニシエーターは現在のESP SAのSPIを含むN（REKEY_SA）通知を追加します。

    SK {N（REKEY_SA）、SA、Ni、[KEi]、TSi、TSr}->
<-SK {SA、Nr、[KEr]、TSi、TSr}

DPD

空のSKとのINFORMATIONAL交換は、デーモン間のハートビートとして、デッドピア検出（DPD）に使用されます。IKEデーモンが長期間使用できない場合は、その状態が失われている可能性が高いため、反対側でESP SAを監視していないか、アクティブではありません。したがって、リモート側が使用できないことが明らかな場合は、関連するすべてのESP / IKESAを削除するのが理にかなっています。空のSKは、ペイロードが含まれていないが、認証されたデータ（少なくとも、カウンター付きのIKEヘッダー）があることを意味します。したがって、このようなパケットの認証は、信頼できる生命の兆候です。

    SK {}->
<-SK {}

しかし、一方の側がすぐに再起動して状態を失い、最初からIKE接続の確立を開始した場合はどうなるでしょうか。反対側は、もう一方が利用できないことに気付かない可能性があり、別のIKE接続で再認証するか新しい子SAを作成することを決定したと考えられます。壊滅的なことは何もありませんが、古いESPSAはまだまともな時間生きることができます。イニシエータは、IKE_AUTH交換にN（INITIAL_CONTACT）アラートを配置して、その側への唯一の既知のIKE接続であることを通知してもよい[MAY]。このような認証された通知を確認したら、明確な良識を持ってすべての古いIKE / ESPSAを削除できます。

DoSと悪いKE

すでにIKE_SA_INITの最初に、一時的な公開キーDHを持つKEiペイロードが送信されます。しかし、イニシエーターはまだIKE SAを交換しておらず、受信側がどのアルゴリズムをサポートしているかをどのようにして知ることができますか？これは、このアドレスに関連付けるために以前に使用されたものを推測したり、長期的なメモリに記憶したりすることしかできません。レスポンダーがアルゴリズムをサポートしていない場合は、N（INVALID_KEY_PAYLOAD）に通知を送信します。これは、優先DHアルゴリズムの識別子を示します。イニシエーターは要求を繰り返す必要がありますが、新しいKEiを使用します。



TLS 1.3：異なるアルゴリズムを使用して、一度に複数の一時的な公開鍵を送信できます。しかし、これらはリソースとトラフィックです。彼は公開鍵をまったく送信しない可能性があり、サーバーはその設定を使用してHelloRetryRequestで応答します。さらに、優先サーバーアルゴリズムがわかるまで、高価な非対称暗号化はまったく使用されませんが、追加のラウンドトリップが発生します。クライアントが最初に不適切な公開鍵アルゴリズムを提供した場合、IKEv2の場合と同様に、選択するアルゴリズムを含むHelloRetryRequestを受け取ります。



しかし、イニシエーターから同じ初期パケットを送信するとどうなりますか？そこで毎回新しいSPIiを生成することが可能です..。レスポンダーは、少なくともDH計算を正直に実行し、IKE_AUTHで応答します。 DHは、CPUとエントロピーのソースを消費する非常にリソースを消費する操作であるため、トランスポンダーが損傷する可能性があります。



IKEv2（IKEv1ではない）では、これに対する保護があり、Cookie文字列を含むアラートを含む応答N（COOKIE）の形式で、その後、イニシエーターは要求を繰り返す必要がありますが、このN（COOKIE）ペイロードを追加します。

           SAi1, KEi, Ni -->
                         <-- N(COOKIE)
SAi1, KEi, Ni, N(COOKIE) -->
                         <-- SAr1, KEr, Nr, [CERTREQ]

リクエストには、最初と同じSPI / Niが必要です。単にペイロードで補足するだけで十分です。レスポンダーは、リクエストと送信されたCookieの間の接続に関する状態を保存でき、それらが一致した後でのみ、イニシエーターによるリクエストへのCookieの追加に関するこの作業を完了した後、レスポンダーは通常の方法でIKE_AUTH交換を続行できます。



ただし、状態をCookie内に直接保存して、「自己認証」にすることは可能です。回答者がイニシエーターからの要求を見たという事実を伝えることができます（少なくともNiとSPIiはそれを見ました）：

Cookie = MAC（some-secret、Ni || SPIi ||タイムスタンプ）

したがって、DoS愛好家は状態を保存し、繰り返されるメッセージをリサイクルする必要があります。これにより、攻撃のコストが大幅に高くなります。DoS攻撃の疑いがある場合にのみ、Cookie保護を有効にして、全員に余分なラウンドトリップを強制しないようにすることは理にかなっています。



TLS 1.3：同様のオプションのセキュリティがあります。サーバーは、クライアントが繰り返されるClientHello2に挿入する必要があるCookie拡張機能を含むメッセージでHelloRetryRequestで応答してもよい[MAY]。

CP

IKEv2を使用すると、IPネットワーク/アドレスの構成をネゴシエートできます。構成ペイロード（CP）を使用すると、構成の受信を要求し（CFG_REQUEST / CFG_REPLYパケットタイプ）、構成を反対側に設定できます（CFG_SET / CFG_ACKタイプ）。構成要求には、当事者が知りたい/設定したい属性が含まれています。属性には、「内部」アドレス、DNSアドレス、DHCP、サブネットナレッジ、または関連するRFCで説明されているその他のタイプがあります。たとえば、IKE_AUTH交換のイニシエータは、イントラネットアドレス（会社のネットワークに接続している）とDNSサーバーを発行するように要求できます。

    SK{IDi, [IDr], AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
<-- SK{IDr,        AUTH, CP(CFG_REPLY),   SAr2, TSi, TSr}

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (proto=0, port=0-65535, :: - ffff:...:ffff)
TSr = (proto=0, port=0-65535, :: - ffff:...:ffff)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:db8::5/64)
  INTERNAL_IP6_DNS(2001:db8::1)
  INTERNAL_IP6_SUBNET(2001:db8:abcd::/64)
TSi = (proto=0, port=0-65535, 2001:db8::5 - 2001:db8::5)
TSr = (proto=0, port=0-65535, 2001:db8::0 - 2001:db8::ffff:ffff:ffff:ffff)

• 2001：db8 :: 5アドレスがイニシエーターに割り当てられます。
• ESP SA 2001:db8::/64 .
• 2001:db8::1 DNS .
• 2001:db8:abcd::/64 , , ESP SA, 2001:db8:: .

Go?

GOSTアルゴリズムを使用したIPsecスタックの最新の国内実装をテストするために、完全に独立した（Linux、FreeBSD、strongSwan、およびその他のスタックからの）実装を作成することにしました。また、Go言語での開発のスピードと容易さのために、GOSTアルゴリズムの既存の実装であるGoGOSTライブラリを使用します。以前、私はすでにGOSTをcrypto / tlsおよびcrypto / x509GoライブラリのTLS1.3実装に統合した経験がありました。gostipsec プロジェクトは、ESPER（ESPv3）とIKER（IKEv2）の2つのデーモンで構成される無料のソフトウェアです。

          ┌──────┐          ┌────┐          ┌─────┐          ┌────┐
          │remote│          │iker│          │esper│          │ipfw│
          └──┬───┘          └─┬──┘          └──┬──┘          └─┬──┘
             │                │                │               │
╔══════╤═════╪════════════════╪════════════╗   │               │
║ UDP  │     │                │            ║   │               │
╟──────┘     │    IKEv2...    │            ║   │               │
║            │ <───────────────            ║   │               │
║            │                │            ║   │               │
║            │    IKEv2...    │            ║   │               │
║            │ ───────────────>            ║   │               │
╚════════════╪════════════════╪════════════╝   │               │
             │                │                │               │
             │                │                │               │
             │    ╔═══════════╪══╤═════════════╪════════════╗  │
             │    ║ UNIX-SOCKET  │             │            ║  │
             │    ╟─────────────setkey-commands│            ║  │
             │    ║           │ ───────────────>            ║  │
             │    ╚═══════════╪════════════════╪════════════╝  │
             │                │                │               │
             │                │                │               │
             │                │   ╔════════════╪═══╤═══════════╪════════════╗
             │                │   ║ DIVERT-SOCKET  │           │            ║
             │                │   ╟──────────────encrypted ESP │            ║
             │                │   ║            │ <──────────────            ║
             │                │   ║            │               │            ║
             │                │   ║            │ decrypted ESP │            ║
             │                │   ║            │ ──────────────>            ║
             │                │   ║            │               │            ║
             │                │   ║            │ unencrypted IP│            ║
             │                │   ║            │ <──────────────            ║
             │                │   ║            │               │            ║
             │                │   ║            │  encrypted IP │            ║
             │                │   ║            │ ──────────────>            ║
             │                │   ╚════════════╪═══════════════╪════════════╝
             │                │                │               │

現時点では、ESPERはDIVERTソケットでのみ機能します（Linuxではそれほど単純なものは見つかりませんでした）。したがって、FreeBSD（おそらくOpenBSD、チェックしなかった）OSでのみサポートされます。 ESPERは、IKERと同様に、ESP <-> IKEバインディング間のインターフェイスとして、Cバインディングを必要とするPF_KEYv2を使用しませんが、記事の冒頭ですでに説明したテキストセットキーのようなインターフェイスを使用します。したがって、IKERを使用して、実際のsetkeyコマンドを呼び出すことにより、カーネルESP実装のキーをネゴシエートすることもできます。 ESPERのこれらのコマンドは次のようになります。

add fc00::ac fc00::dc esp 0x12345678 -u 123 -E aes-gcm-16 0xd3537e657fde5599a2804fbb52d1aaed94b65d3e ;
add fc00::dc fc00::ac esp 0x12345679 -u 234 -E aes-gcm-16 0x9a2dae68e475eacb39d41f23c3cbef890e9f6276 tfc:1320 ;

spdadd fc00::ac/128 fc00::dc/128 all -P in ipsec esp/transport//unique:123 ;
spdadd fc00::dc/128 fc00::ac/128 all -P out ipsec esp/transport//unique:234 ;

エスパーサポート：AES-128/256 GCM-16、マグマ/バッタ-MGM、ESN、TFC、トランスポート/トンネルモードはIPv6 / IPv4の（後者のサポート、はるかに複雑で、十分にテストされておらず、誰のIPv4を必要とするため新しいプロジェクト？）、リプレイ攻撃に対する保護。IKERでは、AES-128 / 256-GCM-16 + AES-XCBC + curve25519、Magma / Grasshopper-MGM + HMAC-Stribog-512 + GOST R 34.10-2012-VKO-256 / 512、ESN / TFC /トランスポートを一致させることができます。 /トンネルモード、PSKおよびX.509デジタル署名（ECDSA、GOST R 34.10-2012）を使用して認証します。単一のHjsonファイルで構成：

{
    IKEAlgos: [
        gost128-vko512
        aes256gcm16-aesxcbc-curve25519
        aes128gcm16-aesxcbc-curve25519
    ]
    ESPAlgos: [
        gost128-esn
        gost64-esn
        aes256gcm16-esn
        aes256gcm16-noesn
        aes128gcm16-esn
        aes128gcm16-noesn
    ]
    SigHashes: [
        streebog512
        streebog256
        sha512
        sha256
    ]
    DPDTimeout: 300
    Peers: [
        {
            Autostart: true
            OurIP: fc00::dc
            TheirIP: fc00::ac
            OurId: our.company.net
            TheirId: CN=example.com
            OurTSS: [
                fc00::dc/128[tcp]
                fc00::dc/128[udp/53]
            ]
            TheirTSS: [
                fc00::ac/128
            ]
            Mode: transport
            # Won't be used, because of X.509 signature authentication
            PSK: DEADBABE
            TheirCertHash: a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
            OurCert: our.company.net.cer.pem
            OurPrvKey: our.company.net.key.pem
            TFC: 1200
        }
    ]
}

この例では、私たちが知っている唯一のメンバーを設定しました。

• どのデーモンに自動的に接続しますか
• 5分ごとにデッドピア検出を実行します
• ESN, fallback- , TFC 1200 .
• TCP DNS fc00::dc fc00::ac .
• X.509 , CN=example.com subject- SHA256 SubjectPublicKeyInfo . OurId OurCert .
• OurCert/OurPrvKey , PSK FQDN OurId.

IKERは、すべてのIKEv2機能（CREATE_CHILD_SA、キーの再生成）の完全なセットをまだサポートしておらず、パケットの損失を監視せず、DO N'TPANICの原則を気にしません。したがって、まだ「産業用」用途の候補とは見なされていません。



Tarball gostipsecには、すべての依存関係、コンパイルされた.infoドキュメント、およびREDOビルドシステムのターゲットがすでに含まれていますが、実行可能ファイルのビルドは、通常のgoビルド呼び出しで簡単に実行できます。

Hjson？

Holywarのテーマですが、とにかくファイをあげます：

• INIでは、このようなスイープ構造を指定することはできません。また、.iniファイルの標準もありません。
• capabilities database , termcap-like, BSD , (, , ), C. IKER .
• XML — .
• JSON — , Python Go . , . - !
• YAML — , , . , . , YAML , , , . . . - . YAML ( ) - ( StrictYAML ).
• TOML — : , , , . , :
  
  
  
  

  [[foo.bar]]
  baz = 123
  
  [[foo.bar]]
  abc = 123
  

  
  
  
  
  :
  
  
  
  

  {
    "foo": {
      "bar": [
        {"baz": 123 },
        {"abc": 123 }
      ]
    }
  }
  

  
  
  «» / , . , TOML, NNCP , . , , .
• Hjson — JSON ( , ), Hjson. github.com/hjson/hjson-go Hjson JSON, . . , . , JSON Hjson.

一般に、TLS 1.3と同様の機能のサブセットを実装する場合（PSKおよびX.509証明書のみによる認証、深刻なキーの再生成はありません）、IKEv2およびIPv6を使用するESPv3（操作がはるかに簡単です！）、プログラマーの観点からは、少し難しくなります。実装中。 RFCは、CREATE_CHILD_SA交換をサポートすることさえ義務付けていません。 TLS 1.3の物議を醸す危険な動作モードがなくても、セキュリティは優れています。核レベルでのトランスポートと長寿命のIKEセッションにより、IPsecソリューションのパフォーマンスは一般的に高くなります。



IPsecでは、ネットワーク全体間の膨大な量のトラフィックを保護するためにすべてがシャープになっていることがわかりますが、BTNS（セキュリティがないよりはましです）IETFワーキンググループは、IPPEがソケットごとの接続に問題なく使用できることを示すいくつかのRFCを作成しました。この場合、当事者の1人（クライアント）は匿名であるため、TLSを使用することの妥当性に完全に疑問を投げかけます。この場合、接続ラッチを使用すると、setsockoptのような簡単なシステム呼び出しを行うことで、任意のネットワークアプリケーションが、FQDN = bank.comアドレスへのESPが必要であることを示し、X.509証明書として提示（または匿名のまま）し、透過的、迅速、かつアプリケーションごとのユーザースペーストランスポートライブラリの形でクラッチを使用せずに、このbank.comで安全に作業します。



セルゲイ・マトベーエフ、サイファーパンク、Python / Go / C-開発者、FGUP STCAtlasのチーフスペシャリスト。