Device Provisioning Protocol (DPP) / Wi-Fi Easy Connect 分析

DPP / Wi-Fi Easy Connect 簡介

日常生活中，我們經常都需要連接不同的 Wi-Fi 熱點。例如：當我們去到咖啡店的時候，通常牆身都會寫上了 Wi-Fi 的 SSID 和密碼。或者當去到朋友家的時候，我們也會問朋友拿 Wi-Fi 的密碼。不過，以這種方法連接 Wi-Fi，其實會帶來兩個潛在的資安風險：「主動攻擊」和「被動攻擊」。

「主動攻擊」是指，有一些黑客，他們會主動去製造一些假的 Wi-Fi AP 基站：只要它們發出同樣的 SSID，設上同樣的密碼，用家就有可能會不小心連上了這些假 AP。只要訊號夠強，速度夠快，大部分用家根本不會發現。這樣，黑客就能發動中間人攻擊 (man-in-the-middle attacks），去盜取用家所有的訊息。

「被動攻擊」則指，黑客們只負責竊聽 (eavesdrop) 在大氣電波中的數據，並不主動發動攻擊。由於密碼都寫在牆上了，所以只要基站 (AP) 與使用者 (STA) 雙方，都沒有用上足夠安全的加密協議（例如只使用了 WEP / WPA / WPA2）的話，黑客就可以輕易將內容解密。

DPP / Wi-Fi Easy Connect 協議的出現，正正是為了解決以上的情況而設計的。簡單來說，在主動攻擊方面，DPP 透過公私鑰的交換，確保用戶只會連到真正的 AP。而在被動攻擊方面，DPP 使用了迪菲-赫爾曼密鑰交換 (Elliptic Curve Diffie-Hellman Key Exchange) 的方法，建立出獨一無二的 session key。所以，即使竊聽者擁有密碼，他們也沒辦法輕易推斷出 session key，繼而也無法解密訊息。  

這篇文章，我只會簡介 DPP 的不同步驟 (steps) 、角色 (roles) 和在 hostap 的實作。關於 Public Private Key Infrastructure (PKI)、Diffie-Hellman 的原理和每個步驟的細節，之後會再寫另一篇解釋。 

DPP 五大步驟

簡單來說，如果只考慮 AP 與 STA 之間的協議，DPP 有以下五大步驟：

• Bootstrapping （起步）：這個步驟是 DPP 的第一步。它指使用頻外驗證 (Out-of-band Authentication) 的方法去交換公鑰。例如將公鑰印成 QR code 貼在牆上、印在機身，或者使用藍芽或 NFC 這類近距離的方法。
  
  
• DPP Authentication（DPP 驗證）：在 bootstrapping 期間成功交換的公鑰，將會用作 HMAC 的參數，繼而產生三條不同的 session keys (k1, k2 以及 ke)。這個步驟主要用作確保雙方均在開機的狀態（又稱為 Aliveness），而且產生出來的 ke 是獨一無二的。
  
  
• DPP Configuration（DPP 設定佈置）：當 authentication 產生了 ke 後，configuration 會用這個 ke （配以 AES-SIV）來加密 Wi-Fi AP 的登入憑證 (credentials / configuration object)。例如，它會包含 SSID, WPA3/WPA2 密碼，或者是 DPP Connector 公私鑰。（如果是 DPP Connector 的話，Connector 入面還包含了 groupId 和 netRole 這些資訊，而且該 connector 會以 ECDSA 簽名，所以任何接收到 connector 的人，都不能擅自改動 connector 的內容。）
  
  
• DPP Network Introduction / Peer Discovery（DPP 設備探索）：這個步驟只適用於有收到 DPP Connector 的情況（如果是 WPA2/3，它就會離開 DPP，走傳統的連線方法）。簡單而言，不同裝置之間會在這步交換 connector，去查核對方的 groupId 和 netRole。如果對方的 netRole 正確，就會繼續產生 Pairwise Master Key (PMK)。例如，如果 AP 擁有一個 groupId="Group1" 和 netRole="ap" 的 connector，而 STA 則擁有一個 groupId="Group1" 和 netRole="sta" 的 connector 的話，因為它有相同的 groupId，而且一個是 ap，另一個是 sta，所以雙方就會同意繼續連線，並且用 connector 中的 netaccesskey 進行 ECDH 及 HKDF，產生 PMK。
  
  
• DPP Network Access / Association（DPP 網絡接入）：最後一步，就是使用在 peer discovery 中產生的 PMK 接入 Wi-Fi AP。這個步驟大致上跟 WPA2 的 PSK 相似，只是把 PSK 換成了 PMK。所以，STA 會以 Open 認證方式連上 AP，再跑 EAPOL (4-way handshake)，從而由 PMK 產生一條新的 PTK。在產生過程中，使用者亦可在 DPP KDE 中表示對 PFS (Perfect Forward Secrecy) 的支援，它就會在接入的過程中，使用 AP 在 RSN IE 中廣播的 Z 公鑰，以加強 PTK 的獨特性。

 

DPP 的四大角色

在官方的文檔中，有四個角色 (Initiator / Responder / Configurator/ Enrollee) 經常出現混淆。
但其實，分類方法十分簡單：

DPP Authentication 中有兩個角色：

• Initiator（發起者）：它接收由 Responder 發出的 DPP URI，然後發出 Authentication Request。 （如果啟用了雙向驗證的話，則兩者互換 DPP URI）
  
• Responder（回應者）：它接收 Authentication Request，並以 Authentication Response 回應 Initiator 的請求。 

DPP Configuration 中有兩個角色：

• Configurator（佈局者）：它儲存了所有憑證 (credentials) 相關的資訊，也會在別人發出 Configuration Request 時，以 Configuration Response 回應它的請求。它也有一條 Certificate Signing Key （又稱 csign key）， 用作簽發 DPP connector 之用。
• Enrollee（登記者）：所有希望接收憑證 (credentials) 的人都是 Enrollee。它們會發出 Configuration Request，等待 Configurator 的回應。
  

 

這四個角色，可以隨著不同的情況完全自由配搭，例如：

• AP (Initiator + Configurator) 配搭 STA (Responder + Enrollee)
• AP 通過掃瞄 STA 的 QR code，令 STA 可以連上 AP
• 這種情況，AP 是路由器的 App，STA 則是 IoT 設備
  
  
• STA (Initiator + Configurator) 配搭 AP (Responder + Enrollee)
• STA 掃瞄 AP 的 QR code，然後設置路由器的 WPA2/3 密碼
  
• 比較少見，但理論上可行
  
  
• STA (Initiator + Configurator) 配搭 STA (Responder + Enrollee)
  
• 兩部手機之間互相分享 WPA2/WPA3 密碼
• Android STA 已部分支援這個功能 (Initiator + Configurator)
  
  
• AP (Responder + Configurator) 配搭 STA (Initiator + Enrollee)
• AP 產生一個 QR code 貼在牆上，其他 STA 一掃就能連上。
• AP 是路由器，STA 是手機
  
  
• STA (Responder + Configurator) 配搭 STA (Initiator + Enrollee) 
• 兩部手機之間互相分享 WPA2/WPA3 密碼
• Android STA 已部分支援這個功能 (Initiator + Enrollee)
  

反正就是，只要你想到的，就可以做到，協議中並沒有限制角色配搭的可能性。

 

在 HostAP 中實作

現時，hostap 2.9 只支援大部分的 DPP 1.0，以及少部分的 DPP 2.0。
而在最新的 commit 中（截稿前是這個），大部分 DPP 2.0 的實作已經做好。

以下的 hostap 指令例子，是以 AP (Initiator + Configurator) + STA (Responder + Enrollee) 為基礎的。你也可以把它想像成這個 use case ：

• hostapd 是路由器
• hostapd_cli 是路由器的手機界面
• wpa_supplicant 和 wpa_cli 是沒有按鈕，只顯示著 QR code 畫面的 IoT 裝置

 

Step 1: STA - 放以下的 config (wpa_dpp.conf):

ctrl_interface=DIR=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
pmf=2
dpp_config_processing=2

 

Step 2. STA - 跑以下的命令，開啟 wpa_supplicant:

./wpa_supplicant -d -Dnl80211 -iwlp1s0 -cwpa_dpp.conf

 

Step 3. STA - 跑以下的命令，產生一條新的 DPP URI QR code，然後等待連線：

./wpa_cli dpp_bootstrap_gen type=qrcode chan=81/1
dpp_bootstrap_get_uri 1
dpp_listen 2412

將產生的 QR code 拷貝下來，在 Step 6 會用到。

 

Step 4. AP - 放以下的 config (hostapd_dpp.conf):

interface=wlp0s20f3
driver=nl80211
ctrl_interface=/var/run/hostapd
ssid=test
channel=1
wpa=2
wpa_key_mgmt=DPP
ieee80211w=1
wpa_pairwise=CCMP
rsn_pairwise=CCMP

 

Step 5. AP - 跑以下的命令，開啟 hostapd:

./hostapd -d hostapd_dpp.conf

 

Step 6.  AP - 打開 hostapd_cli，並貼上剛拷貝的 DPP URI 到以下的命令中

./hostapd_cli
dpp_qr_code <YOUR COPIED DPP URI>

 

Step 7. AP - 在 hostpad 中加一個 configurator。這個 configurator 將會用來簽發所有裝置（包括 ap 自己）的 DPP connectors :

dpp_configurator_add

 

Step 8. AP - 用 configurator 為 ap 自己，簽發一個 connector。在 Peer Discovery 中，每一個裝置都是用 connector 去交換身分資料，所以，ap 自己也需要一個 connector：

dpp_configurator_sign conf=ap-dpp ssid=74657374 configurator=1

 

Step 9. AP - 把剛剛 configurator 產生的 connector 套用到 ap 本身身上。這樣，當有 peer discovery request 的時候，ap 就可以把自己的 connector 傳出去，而且也懂得用套用上的 csign public key 驗證對方的 connector：

set dpp_connector <CONNECTOR VALUE IN TERMINAL>
set dpp_csign <CSIGN VALUE IN TERMINAL>
set dpp_netaccesskey <NETACCESSKEY VALUE IN CONSOLE>

注意這裏的 connector 是已經簽好的 base64 字串，裏面包含了 groupId, netRole, netaccesskey 的public key 和一個 ECDSA 簽名。這個 csign key 則是 public key （csign key 的 private key 是藏在 configurator 裏面的）。而最後，這個 netaccesskey 則是 private key，用作給 ap 在 peer discovery 時產生 PMK 之用。

 

Step 10. AP - 因為 AP 是 initiator 及 configurator，所以要跑以下命令，發起 DPP authentication request。這個命令也要求 configurator 在 configuration response 期間，產生一個 netrole=sta, ssid=test 的 dpp connector 回傳給對方 :

dpp_auth_init peer=1 conf=sta-dpp ssid=74657374 configurator=1

 

小結

DPP (Device Provisioning Protocol，又名 Wi-Fi Easy Connect）是近年來比較新的 Wi-Fi 驗證方法。雖然它仍然需要 out-of-band 的方法去做第一步，而且步驟繁瑣，但至少也算是提供了一個可行的做法。

它的設計邏輯，其實跟 USB Type C 也有點類似：它提供了同一樣的接口，讓兩個裝置至少溝通得上，但實際支援與否，則要看它在交換的過程中，對方的 role 與自己是否配搭。

作為 protocol designer，我認為 DPP 的 signalling messages 實在有點多，而且對 WPA2 的 backward compatibility 可能會令所有事情功虧一簣。但另一方面，正正因為它把步驟都拆分得很細，它也可以在耗用系統資源較少的情況下，及早辨認出 DoS flooding 的封包。這一點，對於未來「萬物皆互聯」的世界，似乎對系統穩定性也有幫助。

但是，如果文檔附有 formal verification 的話，我相信說服力應該會再大一點。

---

引用

[1] - Wi-Fi Easy Connect Spec 2.0 - https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi_Easy_Connect_Specification_v2.0.pdf

[2] - AOSP Wi-Fi Easy Connect - https://source.android.com/devices/tech/connect/wifi-easy-connect

Introduction to 5G Authentication Security

Introduction
Upon switching on mobile phone, it will start to search for available cellular networks nearby, and register itself into the subscribed network using some secrets in USIM card. In this chapter, we will discuss how 5G-AKA has improved the security of this process. However, in order to understand it better, we need to go through some history from 2G (GSM), 3G (UMTS) and 4G (LTE) first. It would help us understand why 5G-AKA is designed in this way.

What is AKA
Authentication and Key Agreement (AKA) is a set of rules (i.e. a protocol) to allow mobile phone and core network to exchange their identity and secret keys for communication. Authentication is a way to make sure both two parties are trustworthy: let say if you want to go to the university library, you will check the address of the library to make sure the library is not a fake one. At the same time, the library staff will also ask you to show your student ID card to make sure that you are the eligible users (e.g. student) of this library. Key agreement is a way of negotiating one common secret key without revealing the key to any third parties. Diffie-Hellman key exchange or computed keys based on common secret are some commonly used methods.

AKA in GSM:
Here is the simplified flow of GSM attach authentication process (EAP-SIM, RFC 4186).

MSC = Mobile Switching Center (the main switch of voice calls)
VLR = Visitor Location Register (a database storing connected devices)
HLR = Home Location Register (the central database of all mobile subscribers details)
AUC = Authentication Center (the functional entity which only focus on running authentication)

In the picture it shows that, when the mobile device is switched on, it will immediately send a request access message which contains the IMSI of the USIM to MSC. Then, VLR will only send a RAND signal to UE to ask for its reply. Also, the final judge of authentication success is located in VLR. As a result, it will have (at least) these 3 main problems:

• By listening to the IMSI in request access messages, eavesdroppers can track a specific device.
• UEs have no way to make sure the cellular network is trustworthy (it just reply a RAND!).
• Authentication decision is made in VLR instead of AUC, which is potentially dangerous.

Not to mention that the predictability of A3 and A8 algorithm could be higher than expected, it is easy to justify that GSM is insecure in many aspects.

---

AKA in 3G (UTRAN, UMTS):
UTRAN (UMTS Terrestrial Radio Access Network) had improved the authentication system slightly. The main focus of the improvements are generating more different keys for different controls. Although the term "temporary identity (pseudonym)" is appeared in EAP-AKA (RFC 4187), the actual implementation still largely follows the GSM way - IMSI is sent in clear text during registration.

---

AKA in 4G (E-UTRAN, LTE):
After some painful lessons from 2G and 3G, 4G LTE tried to tackle the problem of mutual authentication and user tracking. Here is the simplified flow of EPS-AKA:

GUTI = Globally Unique Temporary Identity
AUTN = Authentication Token

After the first registration which uses IMSI, the USIM will be assigned with a new temporary identity called GUTI. This GUTI will be used for next registration, and it will be updated periodically to prevent eavesdroppers to trace the device easily. Besides, since the cellular network will send an extra field (AUTN) to UE as a feedback, UE can use it to make sure the network is legitimate. Unfortunately, there are still some problems found:

• EPS-AKA is still prone to man-in-the-middle (MITM) attack (check here). This is largely because by the time of releasing EPS-AKA, no formal verification was done, so nobody discovered it at the beginning.
• GUTI are not changed as frequently as necessary, and it is easily predictable.
• Authentication decision is still made on MME instead of HSS, which is still dangerous.

Some people asked why 4G LTE is still widely used with so many security issues.
However, think about that:

• Expensive equipment - buying eNB from market is generally expensive for hackers.
• Legislation - radio frequently usage is strictly monitored by government, and the location of fake stations can actually be traced quite easily.
• Lack of alternatives - there is no other choice in the market until 5G launch.

---

AKA in 5G (5GC, NR):
Finally, we have come to 5G era. The new implementation looks like the following:

If you look close enough, you will find that the authentication process still looked very similar to EPS-AKA. However, there are some major improvements:

• SUCI is an encrypted SUPI (IMSI in EPS core network), therefore, even in the first registration UE will not reveal its identity to eavesdropper.
• New entities such as "SEAF", "AUSF", "UDM/ARPF" are created to split the tasks to many servers/entities.
• Authentication decision cannot be solely done in SEAF (which is located in AMF). In fact, SEAF can reject the authentication at any time, but it can only approve authentication after receiving the authenticate response from AUSF.

In fact, there are some researchers doing formal verification of 5G-AKA, and they provided quite reasonable comments about it (check here).

By the way, since 5G supports Non-3GPP AN, 5GC will support various AKA protocols such as EAP-AKA' (improved EAP-AKA) and EAP-TLS. Also there will be a specific functional entity (N3IWF) to handle the signal transmission in Non-3GPP AN. Since this part is also quite complicated, so I will skip it until I need to write them.

---

Reference:

[1]: A Comparative Introduction to 4G and 5G Authentication - https://www.cablelabs.com/insights/a-comparative-introduction-to-4g-and-5g-authentication
[2]: Authentication In GSM - https://www.youtube.com/watch?v=82NYPC3zwiA
[3]: GSM Authentication Procedure - https://diameter-protocol.blogspot.com/2013/06/gsm-2g-authentication-procedure.html
[4]: UTRAN Authentication Procedure - https://diameter-protocol.blogspot.com/2013/06/umts-3g-utran-authentication-procedure.html
[5] - 3GPP 33.501 V15.2 - https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169

5G Security Architecture 安全架構初探

引言
理論上，5G（第五代流動通信）不但具有更快的速度、更高的頻譜效益，還有更高的安全性。 其中一個具體例子，就是手機註冊流程。相比起 4G 使用的 EPS-AKA，5G 使用的 5G AKA 既能更加有效防止竊聽者的追蹤，也能減少在漫遊下，手機身分被盜用的風險。

本文章會先分析 5G Core 中，與保安相關的 Functional Entities 的名稱及功能。然後在下一篇文章，會詳細解釋 5G-AKA 的運作原理，以及與 4G EPS-AKA 的異同之處。

基本保安架構

名詞解釋：

• ME = Mobile Equipment 
• USIM = Unique Subscriber Identity Module
• 3GPP / Non-3GPP AN = 3GPP / Non-3GPP Access Network
• SN = Serving Network
• HE = Home Environment

簡單來說，就是 ME（手機）會與 USIM（電話卡）交換資料，為上層的應用提供保安。
而手機會利用 3GPP AN（例如基地台）或 Non-3GPP AN（例如 Wi-Fi 熱點）與 Serving Network（最就近的網絡）溝通。同時，Serving Network 也需要索取有關你 USIM 的資料，用作認證身分。而且，Serving Network 有時未必是 Home Environment（你訂購的網絡）（例如漫遊情況下）。所以，兩者會一起合作，為上層提供保安。

四個主要的保安個體 (Four Fundamental Entities)

• UE (User Equipment) - 毋庸置疑，手機終端是最重要的個體。
  手機中會插著 USIM 卡，而且手機正正就是資料的使用者。
• AMF (Access and Mobility Management Function) - 它與 4G EPC 的 MME (Mobility Management Entitiy) 十分相似。與 MME 不同：它不會處理與 Session 相關的工作，只會把 Session 相關的訊息 forward 去 SMF 處理。但是，與 MME 相似：它也會處理 Mobility Event 的 Notification。在保安方面，它只會負責做 SEAF (Security Anchor Functionality)，把 SUPI / SUCI 的 request / response forward 去 AUSF / UE。
• AUSF (Authentication Server Function) - 它只負責做 Authentication 相關的工作，也就是處理所有來自 3GPP / Non 3GPP AN 的 5G AKA / EAP-AKA' / EAP-TLS 的請求。
• UDM (User Data Function) - 又稱 ARPF (Authentication credential Repository and Processing Function)。它就是一個儲存 SUPI 和所有 secret key 的倉庫。與 4G 的 HSS 一樣，它只會回應合法的請求。而且，它保證所有 Secret keys 都不會離開它，因為它只會回應 hashed keys / calculated keys。而與 4G HSS 不同：4G HSS 有很多其他功能，而 UDM 只有這一個功能，所以相對簡單。

5GC 的明確分工，不但有助防止伺服器過度繁忙，更令局部強化變得簡單。例如：如果有非常多人進行 5G-AKA，只需要開多一台 AUSF 即可解決。又例如，如果某一天需要改掉 secret key 的加密方法，我們只需要更新一下 UDM 就可以，而不會影響 HSS 的其他功能。

註：SMF (Session Management Function) 與 4G 的 SGW 相似，它只做 Session Management，並不提供保安相關功能。而 UPF (User Plane Function) 也一樣，只根據用戶身分，進行 application detection 和 QoS control，同樣不會提供保安相關功能。

---

參考：

[1] 3GPP 23.501 V15.7 - https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144

[2] 3GPP 33.501 - V15.2 - https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169