この記事は Qiitaコラボ記事 です。GitHubに置いてある Markdownファイルを Qiitaユーザーで作成・編集しアップロードしています。
この記事は『KRACK Attacks: Breaking WPA2』https://www.krackattacks.com/ の翻訳です。（翻訳途中。共同翻訳求む）
前書き
保護された Wi-Fi ネットワークで最近一番利用されているプロトコルである WPA2 の重大な脆弱性を発見しました。アタッカー（以下攻撃者）は、KRACKs （Key Reinstallation Atta cks, 以下 「Key Reinstallation」攻撃 ) と呼ばれる手法で、特定の範囲の利用者に対してこの脆弱性を利用することができます。具体的には、攻撃者はこの新しい攻撃手法を使用して、以前は安全に暗号化されていると思われていた情報を読み取ることができます。これは、クレジットカード番号、パスワード、チャットメッセージ、電子メール、写真などの機密情報を盗むために悪用される可能性があります。 この攻撃は、最新の保護されているすべての Wi-Fi ネットワークに対して有効です。ネットワーク構成によっては、データの注入や操作も可能です。たとえば、攻撃者はランサムウェアやマルウェアを Web サイトに挿入できる可能性があります。
この脆弱性は Wi-Fi の標準自体にあり、個々の製品や実装にはありません。したがって、正しく実装されているすべての WPA2 が影響を受ける可能性があります。ユーザーが攻撃を防止するためには、セキュリティ更新プログラムが入手可能になりしだい、影響を受ける製品を更新する必要があります。お使いのデバイスが Wi-Fi をサポートしている場合、影響を受ける可能性が最も高いことに注意してください。私たちの初期調査では、 Android、 Linux、 Apple、 Windows、 OpenBSD、 MediaTek、 Linksys、その他のすべてが、この攻撃を種とした攻撃に影響を受けることがわかりました。特定の製品に関する詳細については、CERT/CC のデータベースを参照するか、各種ベンダーにお問い合わせください。
この攻撃に関する研究発表は、「Computer and Communications Security」(CCS)、「BLACK HAT」ヨーロッパ会議で発表される予定です。また、私たちの詳細な研究論文はすでにダウンロード可能です。
デモンストレーション
As a proof-of-concept we executed a key reinstallation attack against an Android smartphone. In this demonstration, the attacker is able to decrypt all data that the victim transmits. For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. This is because Android and Linux can be tricked into (re)installing an all-zero encryption key (see below for more info). When attacking other devices, it is harder to decrypt all packets, although a large number of packets can nevertheless be decrypted. In any case, the following demonstration highlights the type of information that an attacker can obtain when performing key reinstallation attacks against protected Wi-Fi networks: https://www.youtube.com/watch?time_continue=3&v=Oh4WURZoR98
概念実証として、私たちは Android スマートフォンに対して「Key Reinstallation」攻撃を実施しました。このデモンストレーションでは、攻撃者は被害者が送信するすべてのデータを復号することができます。攻撃者にとって、これは簡単に達成できることです。なぜなら、私たちの「Key Reinstallation」攻撃は、Linux や Android 6.0 以上に対して桁外れに破壊的であるからです。これは Android と Linux に、暗号化キーがすべてゼロのものをインストール（もしくは再インストール）して騙すことができるからです。（詳細については下記を参照。）他のデバイスを攻撃する場合、すべてのパケットを解読することは難しいのですが、多数のパケットを解読することは可能です。いずれの場合でも、次のデモンストレーションでは保護された Wi-Fi ネットワークに対して、「Key Reinstallation」攻撃を実行した際に攻撃者が取得できる情報の種類をハイライトしています。 https://www.youtube.com/watch?time_continue=3&v=Oh4WURZoR98
Our attack is not limited to recovering login credentials (i.e. e-mail addresses and passwords). In general, any data or information that the victim transmits can be decrypted. Additionally, depending on the device being used and the network setup, it is also possible to decrypt data sent towards the victim (e.g. the content of a website). Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.
私たちの攻撃は（電子メールアドレスやパスワードなどの）ログイン情報の復元に限定されません。一般的に、被害者が送信するデータまたは情報はすべて復号できます。さらに、使用されているデバイスやネットワークの設定によっては、被害者に送信されたデータ（たとえばウェブサイトのコンテンツ）を復号することもできます。ウェブサイトやアプリでは HTTPS をさらなる保護層として使用することがありますが、この二重保護さえも憂慮すべき状況でバイパスされる可能性があると警告します。たとえば、非ブラウザ系のソフトウェア、Apple の iOS と OS X 、Android アプリ、そして Android アプリ、銀行のアプリ、そしてさらに VPN アプリでさえも以前はバイパスされていました。
詳細
Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):
私たちの攻撃は、主に WPA2 プロトコルの 4ウェイ-ハンドシェイクに対するものです。このハンドシェイク（応答確認）は、クライアントが保護された Wi-Fi ネットワークに参加したいときに実行され、クライアントとアクセスポイントの両方が正しい認証情報（ネットワークの事前共有パスワードなど）を所有していることを確認するために使用されます。同時に、4ウェイ-ハンドシェイクは、以降のすべてのトラフィックを暗号化するために使用される新しい暗号化キーについても交渉します。現在、モダンなセキュリティで保護されているすべての Wi-Fi ネットワークでは、4ウェイ-ハンドシェイクが使用されています。これは、これらのネットワークのすべてが攻撃の影響を受けることを意味します。たとえば、この攻撃は、個人および企業の Wi-Fi ネットワーク、古い WPA および最新の WPA2 標準、さらには AES のみを使用するネットワークに対しても機能します。 このWPA2に対する私たちの攻撃は、すべて「Key Reinstallation」攻撃（通称「KRACK」）と呼ばれる新しい技術を使用しています。
キーの再インストール攻撃：高度な説明
In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice.
「Key Reinstallation」攻撃では、攻撃者は既に使用中のキーを再インストール（再設定）するように犠牲者側を騙します。これは、ハンドシェイクメッセージを操作して、暗号化の手続きを再現することによって達成されます。犠牲者が鍵を再インストールすると、増分送信パケット数（すなわち、ノンス）および受信パケット数（すなわち、リプレイカウンタ）などの関連パラメータがそれらの初期値にリセットされてしまいます。基本的には、セキュリティを担保するために、鍵は一度だけインストールして使用する必要があります。しかし、残念ながら WPA2 プロトコルでは保証されていないことに我々は気づきました。暗号化ハンドシェイクを操作することにより、実際にこの弱点を悪用される可能性があります。
「Key Reinstallation」攻撃：4ウェイ-ハンドシェイクに対する具体的な例
As described in the introduction of the research paper, the idea behind a key reinstallation attack can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.
研究論文の紹介に記載されているように、「Key Reinstallation」攻撃の背後にある重要な概念は、以下のように要約できます。クライアントがネットワークに参加すると、新しい暗号化キーを生成するために 4ウェイ-ハンドシェイクが行われます。4ウェイ-ハンドシェイクのメッセージ 3 を受信した後、このキーがインストールされます。一度キーがインストールされると、以降のデータフレームは暗号化プロトコルを使用して通常の暗号化に使用されます。ただし、メッセージは失われたり削除される可能性があるため、アクセスポイント（AP）は、確認応答として適切な応答を受信しなかった場合、メッセージ 3 を再送信します。その結果、クライアントはメッセージ 3 を複数回受信する可能性が出てきます。このメッセージを受信するたびに、同じ暗号化キーを再インストールし、暗号化プロトコルで使用される増分送信パケット番号（nonce）と受信再生カウンタをリセットします。私たちは、攻撃者が 4ウェイ-ハンドシェイクのメッセージ 3 の再送信を収集して再生することによって、これらの増分送信パケット番号（nonce）の強制リセットを強制することができることを示しました。このようにナンス（nonce）の再使用を強制することによって、暗号化プロトコルを攻撃することができ、例えば、パケットを再生、復号、および/または偽造することができます。同じテクニックを用いて、グループ鍵、 PeerKey、 TDLS、および fast BBS トランジッション・ハンドシェイクを攻撃することもできます。
実用的なインパクト
In our opinion, the most widespread and practically impactful attack is the key reinstallation attack against the 4-way handshake. We base this judgement on two observations. First, during our own research we found that most clients were affected by it. Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies. Decryption of packets is possible because a key reinstallation attack causes the transmit nonces (sometimes also called packet numbers or initialization vectors) to be reset to zero. As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.
私たちの意見では、4ウェイ-ハンドシェイクに対する「Key Reinstallation」攻撃が最も広く普及し影響力のある攻撃になると考えています。この判断は、次の 2 つの観察に基づいて我々は行いました。まず、私たち自身の研究の最中に、ほとんどのクライアントがその影響を受けていることがわかりました。第 2 に、攻撃者はこの攻撃を使用してクライアントから送信されたパケットを復号し、パスワードやクッキーなどの機密情報を傍受することができました。パケットの復号が可能な理由は、「Key Reinstallation」攻撃により送信ナンス（パケット番号または初期化ベクトルとも呼ばれることもある）がゼロにリセット（初期化）されるためです。その結果、過去にすでに使用されていたnonce値と同じ暗号化キーが使用されます。さらに、以降の WPA2 のすべての暗号化プロトコルのパケット暗号化にキーストリームが再利用されます。パケットを暗号化する際、再利用されるキーストリームのメッセージに既知のコンテンツがある場合、使用されているキーストリームを導出することは簡単です。このキーストリームを使用して、同じナンスでメッセージを復号することができます。既知のコンテンツがない場合は、パケットを復号することは難しくなりますが、いくつかのケースでは可能です（たとえば英語のテキストは引き続き復号できます）。 実際には、既知の内容のパケットを見つけることは問題ではないので、どのパケットも復号できると想定する必要があります。
The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to obtain the TCP sequence numbers of a connection, and hijack TCP connections. As a result, even though WPA2 is used, the adversary can now perform one of the most common attacks against open Wi-Fi networks: injecting malicious data into unencrypted HTTP connections. For example, an attacker can abuse this to inject ransomware or malware into websites that the victim is visiting.
パケットを解読できるなら TCP 接続用パケットも解読できます。このことは、敵対者が接続用の TCP シーケンス番号を取得し、TCP接続を乗っ取ることを可能にします。その結果、WPA2 が使われていたとしても、敵対者は暗号化されていない HTTP 接続に悪意あるデータを挿入するといった公開 Wi-Fi ネットワークで最も一般的な攻撃を直ちに実行できます。例えば、攻撃者は犠牲者が訪れているウェブサイトにランサムウェアやマルウェアを挿入するためにこれを乱用できます。
If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets. Moreover, because GCMP uses the same authentication key in both communication directions, and this key can be recovered if nonces are reused, it is especially affected. Note that support for GCMP is currently being rolled out under the name Wireless Gigabit (WiGig), and is expected to be adopted at a high rate over the next few years.
もし犠牲者が、暗号化手順として、AES-CCMP の代わりに WPA-TKIP か GCMP のどちらかを使っているなら、影響は特に甚大です。これらの暗号化手順に対し、ナンスの再利用は、敵対者にパケットの解読だけでなく、偽造や挿入も可能にします。さらに、GCMP は双方向通信において同じ認証キーを使い、このキーがナンスの再利用を可能にするため、影響は甚大となります。GCMP のサポートは現在ワイギグ（Wireless Gigabit, WiGig）という名称で製品展開され、次の数年間のうちに高速（通信）で採用される予定になっています。
The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client. Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames. For further details, see Section 6 of our research paper.
パケットが解読（そしておそらく偽造）されるかどうかは、ハンドシェイクが攻撃されているかに依ります。単純に、4ウェイ-ハンドシェイクが攻撃されているなら、我々はクライアントから送られてきたパケットを解読（偽造）できます。高速ローミング機能のハンドシェイクが攻撃されているなら、我々はクライアントに送るパケットを解読（偽造）できます。
最終的に、我々の攻撃はほとんどの場合、１対１、１対全、1対複数のフレームの再生を可能にします。詳細は、研究論文のセクション６を参照のこと。
Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.
我々の攻撃は、Wi-Fiネットワークのパスワードを復元していないし、また、4ウェイ-ハンドシェイク中に通用したばかりの暗号化キー（のいかなる部分）も復元していないことに注意してください。
Android および Linux
Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key. Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack.
我々の攻撃は、Linux で一般的に使われている Wi-Fi クライアントの wpa_supplicant の 2.4 以降（のバージョン）で特に致命的です。ここでは、クライアントは実キーを再インストールする代わりに全てゼロの暗号化キーをインストールします。この脆弱性は初めてインストールされた暗号化キーはメモリから消去するようにとする Wi-Fi 規格で提案された意見によって起きているようです。クライアントが 4ウェイ-ハンドシェイクの再送されたメッセージ 3 を受け取ると直ちにそれはクリアされた全てゼロの有効な暗号化キーに再インストールされます。Android は wpa_supplicant を使用しますので、Android 6.0 以降にもこの脆弱性が含まれています。このことは、そういった Linux と Android の機器から送られたトラフィックを傍受や操作するのを容易にします。現在、41% の Android 機器が我々の攻撃の非常に壊滅的な変化に対して脆弱です。
追加翻訳募集中
以下自動翻訳（2017/10/21）
割り当てられたCVE識別子
The following Common Vulnerabilities and Exposures (CVE) identifiers were assigned to track which products are affected by specific instantiations of our key reinstallation attack:
次のCommon Vulnerabilities and Exposures（CVE）識別子は、キー再インストール攻撃の特定のインスタンス化によって影響を受ける製品を追跡するために割り当てられています。
- CVE-2017-13077：4ウェイ-ハンドシェイクでペア暗号化キー（PTK-TK）を再インストールする。
- CVE-2017-13078：4ウェイ-ハンドシェイクにおけるグループキー（GTK）の再インストール。
- CVE-2017-13079：44ウェイ-ハンドシェイクにおけるインテグリティグループキー（IGTK）の再インストール。
- CVE-2017-13080：グループ鍵ハンドシェイクにおけるグループ鍵（GTK）の再インストール。
- CVE-2017-13081：グループ鍵ハンドシェイクにおける整合性グループ鍵（IGTK）の再インストール。
- CVE-2017-13082：再送された高速BSS移行（FT）再関連付け要求を受け入れ、ペアワイズ暗号化キー（PTK-TK）を処理中に再インストールします。
- CVE-2017-13084：PeerKeyハンドシェイクにおけるSTKキーの再インストール。
- CVE-2017-13086：TDLSハンドシェイクにおけるTunneled Direct-Link Setup（TDLS）PeerKey（TPK）キーの再インストール。
- CVE-2017-13087：ワイヤレスネットワーク管理（WNM）スリープモード応答フレームを処理する際のグループキー（GTK）の再インストール。
- CVE-2017-13088：ワイヤレスネットワーク管理（WNM）スリープモード応答フレームを処理する際のインテグリティグループキー（IGTK）の再インストール。
Note that each CVE identifier represents a specific instantiation of a key reinstallation attack. This means each CVE ID describes a specific protocol vulnerability, and therefore many vendors are affected by each individual CVE ID. You can also read vulnerability note VU#228519 of CERT/CC for additional details on which products are known to be affected.
各CVE識別子は、鍵の再インストール攻撃の特定のインスタンス化を表します。つまり、各CVE IDには特定のプロトコルの脆弱性が記述されているため、多くのベンダーは個々のCVE IDの影響を受けます。あなたも読み取ることができる脆弱性ノートVU＃228519製品が影響を受けることが知られている上、追加の詳細については、CERT / CCのを。
論文
Our research paper behind the attack is titled Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 and will be presented at the Computer and Communications Security (CCS) conference on Wednesday 1 November 2017.
この攻撃の背後にある私たちの研究論文は、WPA2のKey Reinstallation Attacks：Nonce Reuseを強制するタイトルであり、2017年11月1日水曜日のComputer and Communications Security（CCS）会議で発表されます。
Although this paper is made public now, it was already submitted for review on 19 May 2017. After this, only minor changes were made. As a result, the findings in the paper are already several months old. In the meantime, we have found easier techniques to carry out our key reinstallation attack against the 4-way handshake. With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper.
この論文は今公開されていますが、2017年5月19日に審査のために提出されました。その後、わずかな変更が加えられました。その結果、この論文の所見はすでに数カ月前になっています。その間、私たちは、4ウェイ-ハンドシェイクに対する主要な再インストール攻撃を実行するためのより簡単なテクニックを見つけました。私たちの斬新な攻撃手法では、4ウェイ-ハンドシェイクのメッセージ3の暗号化された再送信のみを受け入れる実装を利用するのは簡単です。特にこれはmacOSとOpenBSDの攻撃がこの論文で議論されているよりはるかに容易であることを意味します。
We would like to highlight the following addendums and errata:
私たちは以下の補遺と正誤表を強調したいと思います：
補遺：wpa_supplicant v2.6およびAndroid 6.0+
Linux's wpa_supplicant v2.6 is also vulnerable to the installation of an all-zero encryption key in the 4-way handshake. This was discovered by John A. Van Boxtel. As a result, all Android versions higher than 6.0 are also affected by the attack, and hence can be tricked into installing an all-zero encryption key. The new attack works by injecting a forged message 1, with the same ANonce as used in the original message 1, before forwarding the retransmitted message 3 to the victim.
Linux の wpa_supplicant v2.6 にも、4ウェイ-ハンドシェイクでオールゼロ暗号鍵をインストールできる脆弱性があります。これはJohn A. Van Boxtelによって発見されました。その結果、6.0より新しいすべてのAndroidバージョンも攻撃の影響を受けるため、すべてゼロの暗号化キーをインストールすることに騙される可能性があります。新しい攻撃は、再送信されたメッセージ3を犠牲者に転送する前に元のメッセージ1で使用されたのと同じANonceを持つ偽造メッセージ1を注入することによって機能します。
補遺：他の脆弱なハンドシェイク
After our initial research as reported in the paper, we discovered that the TDLS handshake and WNM Sleep Mode Response frame are also vulnerable to key reinstallation attacks.
この論文で報告された最初の調査の結果、TDLSハンドシェイクとWNMスリープモード応答フレームも主要な再インストール攻撃に対して脆弱であることがわかりました。
選択された正誤表
- In Figure 9 at stage 3 of the attack, the frame transmitted from the adversary to the authenticator should say a ReassoReq instead of ReassoResp.
- 攻撃のステージ3の図9では、敵対者からオーセンティケータに送信されたフレームはReassoRespの代わりにReassoReqと言わなければなりません。
ツール
We have made scripts to detect whether an implementation of the 4-way handshake, group key handshake, or Fast BSS Transition (FT) handshake is vulnerable to key reinstallation attacks. These scripts will be released once we had the time to clean up their usage instructions.
私たちは、4ウェイ-ハンドシェイク、グループキーハンドシェイク、またはFast BSS Transition（FT）ハンドシェイクの実装が主要な再インストール攻撃に対して脆弱かどうかを検出するスクリプトを作成しました。これらのスクリプトは、使用方法を整理してから解放されます。
We also made a proof-of-concept script that exploits the all-zero key (re)installation present in certain Android and Linux devices. This script is the one that we used in the demonstration video. It will be released once everyone had a reasonable chance to update their devices (and we have had a chance to prepare the code repository for release). We remark that the reliability of our proof-of-concept script may depend on how close the victim is to the real network. If the victim is very close to the real network, the script may fail because the victim will always directly communicate with the real network, even if the victim is (forced) on a different Wi-Fi channel than this network.
また、特定のAndroidおよびLinuxデバイスに存在するゼロキー（再）インストールを利用する概念実証スクリプトを作成しました。このスクリプトは、デモンストレーションビデオで使用したスクリプトです。誰もがデバイスを更新するための妥当な機会を得たら、リリースされます（リリースのためにコードリポジトリを準備する機会がありました）。概念実証スクリプトの信頼性は、被害者が実際のネットワークにどのくらい近いかによって異なります。犠牲者が実際のネットワークに非常に近い場合、犠牲者がこのネットワークとは異なるWi-Fiチャネルで（強制的に）犠牲になっても、実際のネットワークと常に直接通信するためスクリプトが失敗する可能性があります。
Q＆A
WPA3が必要ですか？
No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access points sends exactly the same handshake messages as before, and at exactly the same moments in time. However, the security updates will assure a key is only installed once, preventing our attacks. So again, update all your devices once security updates are available.
いいえ、幸いにも、実装は後方互換性のある方法でパッチすることができます。つまり、パッチを適用したクライアントはパッチの適用されていないアクセスポイントと通信することができ、その逆もあります。言い換えれば、パッチされたクライアントまたはアクセスポイントは、以前とまったく同じハンドシェークメッセージを正確に同じ時刻に送信します。しかし、セキュリティアップデートは、キーが一度だけインストールされることを保証し、私たちの攻撃を防ぎます。セキュリティアップデートが利用可能になると、再度、すべてのデバイスを更新してください。
Wi-Fiパスワードを変更する必要がありますか？
Changing the password of your Wi-Fi network does not prevent (or mitigate) the attack. So you do not have to update the password of your Wi-Fi network. Instead, you should make sure all your devices are updated, and you should also update the firmware of your router. After updating your router, you can optionally change the Wi-Fi password as an extra precaution.
Wi-Fiネットワークのパスワードを変更しても、攻撃は防止（または緩和）されません。したがって、Wi-Fiネットワークのパスワードを更新する必要はありません。代わりに、すべてのデバイスが更新されていることを確認し、ルータのファームウェアも更新する必要があります。ルーターを更新した後、Wi-Fiパスワードを追加の予防措置として変更することもできます。
私はWPA2とAESのみを使用しています。それも脆弱ですか？
Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP). So everyone should update their devices to prevent the attack!
はい。そのネットワーク構成も脆弱です。この攻撃は、WPA1およびWPA2、個人およびエンタープライズネットワーク、および使用されている暗号スイート（WPA-TKIP、AES-CCMP、およびGCMP）に対して実行されます。誰もが攻撃を防ぐためにデバイスを更新する必要があります！
あなたはこのウェブサイトで「私たち」という言葉を使用します。私たちは誰ですか？
I use the word "we" because that's what I'm used to writing in papers. In practice, all the work is done by me, with me being Mathy Vanhoef. My awesome supervisor is added under an honorary authorship to the research paper for his excellent general guidance. But all the real work was done on my own. So the author list of academic papers does not represent division of work :)
私は「私たち」という言葉を使っています。なぜなら、それは私が論文で書くのに慣れているからです。実際には、すべての仕事は私によって行われ、私はMathy Vanhoefである。彼の優れた一般的な指導のために私のすばらしい上司が名誉の著者のもとで研究論文に追加されます。しかし、すべての実際の仕事は私自身で行われました。したがって、学術論文の著者リストは仕事の分業を表すものではありません:)
私のデバイスは脆弱ですか？
Probably. Any device that uses Wi-Fi is likely vulnerable. Contact your vendor for more information.
多分。Wi-Fiを使用するデバイスは、脆弱性が高い可能性があります。詳細については、ベンダーにお問い合わせください。
ルータのセキュリティアップデートがない場合はどうなりますか？
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
私たちの主な攻撃は4ウェイ-ハンドシェイクに対するもので、アクセスポイントを利用するのではなく、クライアントをターゲットにしています。したがって、ルータにセキュリティアップデートが必要ない場合があります。詳細については、ベンダーに問い合わせることを強くお勧めします。ただし、クライアント機能（たとえばリピータモードで使用）を無効にし、802.11r（高速ローミング）を無効にすることで、ルータとアクセスポイントに対する攻撃を緩和することができます。通常の家庭のユーザーにとっては、ラップトップやスマートフォンなどのクライアントを更新することが優先事項です。
どのようにしてこれらの脆弱性を発見しましたか？
When working on the final (i.e. camera-ready) version of another paper, I was double-checking some claims we made regarding OpenBSD's implementation of the 4-way handshake. In a sense I was slacking off, because I was supposed to be just finishing the paper, instead of staring at code. But there I was, inspecting some code I already read a hundred times, to avoid having to work on the next paragraph. It was at that time that a particular call to ic_set_key caught my attention. This function is called when processing message 3 of the 4-way handshake, and it installs the pairwise key to the driver. While staring at that line of code I thought “Ha. I wonder what happens if that function is called twice”. At the time I (correctly) guessed that calling it twice might reset the nonces associated to the key. And since message 3 can be retransmitted by the Access Point, in practice it might indeed be called twice. “Better make a note of that. Other vendors might also call such a function twice. But let's first finish this paper...”. A few weeks later, after finishing the paper and completing some other work, I investigated this new idea in more detail. And the rest is history.
最終的な（つまりカメラ対応の）別の用紙で作業するとき、OpenBSDの4ウェイ-ハンドシェイクの実装に関するいくつかの主張を再確認しました。ある意味では、コードを見るのではなく、ちょうど紙を仕上げることになっていたので、私は慌てていました。しかし、そこに私はすでに何百回も読んだコードを調べて、次の段落で作業することを避けていました。その時、ic_set_keyへの特定の呼び出しが私の注意を引いた。この関数は、4ウェイ-ハンドシェイクのメッセージ3を処理するときに呼び出され、ペアワイズキーをドライバにインストールします。そのコード行を見て、私は"Ha。その関数が2回呼び出されるとどうなるのだろうか "。その時、私は（正しく）2回呼び出すとキーに関連付けられたナンスをリセットするかもしれないと正しく推測しました。また、メッセージ3はアクセスポイントによって再送信できるので、実際には2回呼び出される可能性があります。"それを書き留めておくとよい。他のベンダーもこのような関数を2回呼び出すことがあります。しかし、「...のは、最初にこの論文を仕上げてみましょう。数週間後、論文を完成させ、他の研究を完了した後、私はこの新しい考え方をより詳細に調査しました。残りは歴史です。
4ウェイ-ハンドシェイクは数学的に安全であることが証明されました。あなたの攻撃はどのように可能ですか？
The brief answer is that the formal proof does not assure a key is installed once. Instead, it only assures the negotiated key remains secret, and that handshake messages cannot be forged.
簡単な答えは、正式な証拠が鍵が一度インストールされたことを保証しないということです。代わりに、それは交渉された鍵が秘密であることを保証するだけであり、そのハンドシェイクメッセージは偽造できません。
The longer answer is mentioned in the introduction of our research paper: our attacks do not violate the security properties proven in formal analysis of the 4-way handshake. In particular, these proofs state that the negotiated encryption key remains private, and that the identity of both the client and Access Point (AP) is confirmed. Our attacks do not leak the encryption key. Additionally, although normal data frames can be forged if TKIP or GCMP is used, an attacker cannot forge handshake messages and hence cannot impersonate the client or AP during handshakes. Therefore, the properties that were proven in formal analysis of the 4-way handshake remain true. However, the problem is that the proofs do not model key installation. Put differently, the formal models did not define when a negotiated key should be installed. In practice, this means the same key can be installed multiple times, thereby resetting nonces and replay counters used by the encryption protocol (e.g. by WPA-TKIP or AES-CCMP).
より長い答えは、私たちの研究論文の紹介に記載されています：私たちの攻撃は、4ウェイ-ハンドシェイクの正式な分析で証明されたセキュリティプロパティに違反しません。特に、これらの証明では、交渉された暗号鍵が秘密のままであり、クライアントとアクセスポイント（AP）の両方の身元が確認されていることが示されています。我々の攻撃は暗号鍵を漏らさない。さらに、TKIPまたはGCMPを使用すると、通常のデータフレームを偽造することはできますが、攻撃者はハンドシェイクメッセージを偽造できないため、ハンドシェイク中にクライアントまたはAPを偽装することはできません。したがって、4ウェイ-ハンドシェイクの正式な分析で証明されたプロパティは真のままです。しかし、問題は、プルーフがキーインストールをモデル化しないということです。言い換えれば、正式モデルは、交渉された鍵をいつインストールするべきかを定義していない。実際には、これは同じキーが複数回インストールできることを意味し、
紙での攻撃は難しいようです
We have follow-up work making our attacks (against for example macOS and OpenBSD) significantly more general and easier to execute. So although we agree that some of the attack scenarios in the paper are rather impractical, do not let this fool you into believing key reinstallation attacks cannot be abused in practice.
私たちは、攻撃（例えばmacOSやOpenBSDに対して）をより一般的で実行しやすくするフォローアップ作業を行っています。したがって、この文書の攻撃シナリオのいくつかはむしろ実用的ではないことに同意しますが、実際の攻撃で悪質な再インストール攻撃を行うことはできません。
攻撃者がman-in-the-middle攻撃を行うことができる場合、なぜ彼はすべてのデータを復号できませんか？
As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a channel-based MitM position). However, this MitM position does not enable the attacker to decrypt packets! This position only allows the attacker to reliably delay, block, or replay encrypted packets. So at this point in the attack, he or she cannot yet decrypt packets. Instead, the ability to reliably delay and block packets is used to execute a key reinstallation attack. After performing a key reinstallation attacks, packets can be decrypted.
デモンストレーションで述べたように、攻撃者は最初に被害者と実際のWi-Fiネットワーク（チャネルベースのMitMポジションと呼ばれる）の中間者（MitM）ポジションを取得します。しかし、このMitMの位置では、攻撃者はパケットを解読することができません！この位置では、攻撃者は暗号化されたパケットを確実に遅延、ブロック、再生することができます。したがって、攻撃のこの時点で、彼または彼女はまだパケットを解読することができません。代わりに、パケットを確実に遅延させてブロックする機能を使用して、鍵の再インストール攻撃を実行します。鍵の再インストール攻撃を実行した後、パケットを復号することができます。
野生の人々がこれを利用していますか？
We are not in a position to determine if this vulnerability has been (or is being) actively exploited in the wild. That said, key reinstallations can actually occur spontaneously without an adversary being present! This may for example happen if the last message of a handshake is lost due to background noise, causing a retransmission of the previous message. When processing this retransmitted message, keys may be reinstalled, resulting in nonce reuse just like in a real attack.
私たちは、この脆弱性が野生で積極的に悪用されているかどうかを判断する立場にありません。つまり、重要な再インストールは、実際に敵がいなくても自発的に発生する可能性があります。これは、例えばバックグラウンドノイズのためにハンドシェイクの最後のメッセージが失われ、前のメッセージの再送信を引き起こした場合に起こります。この再送信されたメッセージを処理するとき、キーが再インストールされる可能性があり、実際の攻撃の場合と同じようにナンスの再利用が行われます。
デバイスにパッチを当てるまでWEPを一時的に使用する必要がありますか？
NO! Keep using WPA2.
**いいえ！**WPA2を使い続ける。
これに対処するためにWi-Fi規格が更新されるのだろうか？
There seems to be an agreement that the Wi-Fi standard should be updated to explicitly prevent our attacks. These updates likely will be backwards-compatible with older implementations of WPA2. Time will tell whether and how the standard will be updated.
明示的に私たちの攻撃を防ぐためにWi-Fi標準を更新する必要があるという合意があるようです。これらのアップデートは、WPA2の古い実装と下位互換性があります。標準が更新されるかどうか、どのように更新されるかは時間によって分かります。
Wi-Fi Allianceはこれらの脆弱性にも対処していますか？
For those unfamiliar with Wi-Fi, the Wi-Fi Alliance is an organization which certifies that Wi-Fi devices conform to certain standards of interoperability. Among other things, this assures that Wi-Fi products from different vendors work well together.
Wi-Fiアライアンスは、Wi-Fiに精通していないユーザーのために、Wi-Fiデバイスが特定の相互運用性基準に準拠していることを証明する組織です。とりわけ、これは異なるベンダーのWi-Fi製品がうまく機能することを保証します。
The Wi-Fi Alliance has a plan to help remedy the discovered vulnerabilities in WPA2. Summarized, they will:
Wi-Fi Allianceは、 WPA2の発見された脆弱性を改善するための計画を立てています。まとめると、彼らは：
- Require testing for this vulnerability within their global certification lab network.
- Provide a vulnerability detection tool for use by any Wi-Fi Alliance member (this tool is based on my own detection tool that determines if a device is vulnerable to some of the discovered key reinstallation attacks).
- Broadly communicate details on this vulnerability, including remedies, to device vendors. Additionally, vendors are encouraged to work with their solution providers to rapidly integrate any necessary patches.
- Communicate the importance for users to ensure they have installed the latest recommended security updates from device manufacturers.
- グローバル認証ラボネットワーク内でこの脆弱性のテストを実施する必要があります。
- 任意のWi-Fi Allianceメンバーが使用する脆弱性検出ツールを提供します（このツールは、検出されたキー再インストール攻撃の一部にデバイスが脆弱かどうかを判断する独自の検出ツールに基づいています）。
- 救済策を含むこの脆弱性に関する詳細をデバイスベンダに広く伝えてください。さらに、ベンダーはソリューションプロバイダーと協力して、必要なパッチをすばやく統合することを推奨します。
- ユーザーがデバイスメーカーから最新の推奨セキュリティ更新プログラムをインストールしたことを確認する重要性を伝えます。
デモビデオでmatch.comを例に使用したのはなぜですか？
Users share a lot of personal information on websites such as match.com. So this example highlights all the sensitive information an attacker can obtain, and hopefully with this example people also better realize the potential (personal) impact. We also hope this example makes people aware of all the information these dating websites may be collecting.
ユーザーはmatch.comなどのウェブサイトで多くの個人情報を共有します。この例では、攻撃者が入手できるすべての機密情報を強調表示しています。この例では、潜在的な（個人的な）影響をよりよく理解することができれば幸いです。この例では、これらの出会い系サイトが収集しているすべての情報を人々に知らせることを願っています。
どのようにしてこれらのタイプのバグを防ぐことができますか？
We need more rigorous inspections of protocol implementations. This requires help and additional research from the academic community! Together with other researchers, we hope to organize workshop(s) to improve and verify the correctness of security protocol implementations.
我々は、プロトコル実装のより厳密な検査を必要とする。これには、学術コミュニティの助けと追加の研究が必要です！他の研究者とともに、セキュリティプロトコル実装の正確性を向上させ、検証するためにワークショップを開催することを望みます。
なぜドメイン名はkrackattacks.comですか？
First, I'm aware that KRACK attacks is a pleonasm, since KRACK stands for key reinstallation attack and hence already contains the word attack. But the domain name rhymes, so that's why it's used.
まず、私はKRACK攻撃であることを承知している冗語 KRACKの略であるため、k個の EYのR einstallation TTAのCKので、すでにワード攻撃が含まれています。しかし、ドメイン名は韻を踏むので、それが使われています。
これに対してバグの恩恵を受けましたか？
I haven't applied for any bug bounties yet, nor have I received one already.
私はまだバグの奨励金を申請しておらず、既に受け取ったこともありません。
この攻撃はWPA2に対する他の攻撃とどのように比較されますか？
This is the first attack against the WPA2 protocol that doesn't rely on password guessing. Indeed, other attacks against WPA2-enabled network are against surrounding technologies such as Wi-Fi Protected Setup (WPS), or are attacks against older standards such as WPA-TKIP. Put differently, none of the existing attacks were against the 4-way handshake or against cipher suites defined in the WPA2 protocol. In contrast, our key reinstallation attack against the 4-way handshake (and against other handshakes) highlights vulnerabilities in the WPA2 protocol itself.
これは、パスワード推測に依存しないWPA2プロトコルに対する最初の攻撃です。実際、WPA2対応ネットワークに対する他の攻撃は、Wi-Fi Protected Setup（WPS）などの周囲の技術に対する攻撃であるか、WPA-TKIPなどの古い標準に対する攻撃です。言い換えれば、既存の攻撃のいずれも、WPA2プロトコルで定義されている4ウェイ-ハンドシェイクまたは暗号スイートに対するものではありませんでした。これとは対照的に、4ウェイ-ハンドシェイク（および他のハンドシェイク）に対する鍵となる再インストール攻撃は、WPA2プロトコル自体の脆弱性を強調します。
他のプロトコルも主要な再インストール攻撃の影響を受けますか？
We expect that certain implementations of other protocols may be vulnerable to similar attacks. So it's a good idea to audit security protocol implementations with this attack in mind. However, we consider it unlikely that other protocol standards are affected by similar attacks (or at least so we hope). Nevertheless, it's still a good idea to audit other protocols!
私たちは、他のプロトコルの特定の実装が同様の攻撃に対して脆弱であると予想しています。したがって、この攻撃を念頭に置いてセキュリティプロトコルの実装を監査することは良い考えです。しかし、他のプロトコル標準も同様の攻撃の影響を受けているとは考えられません。それにもかかわらず、他のプロトコルを監査することはまだ良い考えです！
より高い解像度のロゴがありますか？
Yes there is. And a big thank you goes to the person that made the logo!
はい、あります。ロゴを作った人には大変感謝しています！
最初にベンダーにこの脆弱性についていつ通知しましたか？
We sent out notifications to vendors whose products we tested ourselves around 14 July 2017. After communicating with these vendors, we realized how widespread the weaknesses we discovered are (only then did I truly convince myself it was indeed a protocol weaknesses and not a set of implementation bugs). At that point, we decided to let CERT/CC help with the disclosure of the vulnerabilities. In turn, CERT/CC sent out a broad notification to vendors on 28 August 2017.
私たちは、2017年7月14日頃にテストした製品を販売しているベンダーに通知を送りました。これらのベンダーとのコミュニケーションの後、我々は発見した弱点がどれくらい広がっているのかを認識しました（私は本当にプロトコルの弱点であり、実装のバグ）。その時点で、CERT / CCに脆弱性の開示を助けることにしました。次に、CERT / CCは2017年8月28日にベンダーに広範な通知を送付した。
なぜOpenBSDは禁輸措置の前に黙ってパッチをリリースしたのですか？
OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
OpenBSDはCERT / CCが調整に関与する前の2017年7月15日にこの脆弱性を通知されました。Theo de Raadtは、暫定公開期限を尋ねた。「オープンソースの世界では、ある人がdiffを書いて1ヶ月間座っていなければ、それは非常に落胆している。私はすでにOpenBSD用の差分を書いておいたので、暫定公開期限は8月末頃でした。妥協として、私は彼らに黙ってこの脆弱性を修正させました。他の人がサイレントパッチを調べてこの脆弱性を再発見する可能性があるので、これは後見では悪い決定でした。将来この問題を回避するために、OpenBSDは禁輸措置の終了時に近い脆弱性通知を受け取るようになります。
だからあなたは他のWi-Fiの脆弱性を見つけることを期待していますか？
“I think we're just getting started.” — Master Chief, Halo 1
「私たちはちょうど始めていると思う」 - ヘロ1長官
CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE | Copyright https://www.krackattacks.com/
| 共同著者 |
|---|
| @KEINOS @Jiro2Bit |