（一百二十三）Android O 了解wifi eap中的anonymous identity

参考：https://security.stackexchange.com/questions/100684/what-is-anonymous-identity-in-enterprise-wpa

 

1.问题

 

2.回答

2.1 回答一

The anonymous identity is used in PEAP (Protected Extensible Authentication Protocol) so that the authenticator can choose the correct authentication server to process the credentials. For example sending anonymous identities of foo@example to Example's RADIUS server.

See here for more information.

The anonymous identity is sent in the clear. Some client systems have a privacy option for the anonymous identity. In this case rather than foo@example being sent in the client response, only @example is sent, protecting the actual identity of the user. All an eavesdropper can see is that they want to authenticate with Example.

后面紧接着有个回复

The anonymous identity is used in a number of different EAP mehtods, not simply by PEAP. Specific to this question, the OP posted a screenshot of the configuration for the use of TTLS, not PEAP and TTLS also can make use of an anonymous identity.

总结一下，匿名身份（anonymous identity）可以让authenticator选择正确的授权服务器来处理凭据，但这不限于PEAP和TTLS才可以用匿名身份，还有其他的，但他没有明说。

探究补充：

2.1.1 名词解释

/**

* anonymous_identity - Anonymous EAP Identity

*

* This field is used for unencrypted use with EAP types that support

* different tunnelled identity, e.g., EAP-TTLS, in order to reveal the

* real identity (identity field) only to the authentication server.

*

* If not set, the identity field will be used for both unencrypted and

* protected fields.

*

* This field can also be used with EAP-SIM/AKA/AKA' to store the

* pseudonym identity.

*/

wpa_supplicant有该条属性的定义，此字段被用在“某些支持不同隧道标识的EAP类型”的未加密使用上，例如EAP-TTLS，以便仅向身份验证服务器揭示真实身份（身份字段）。

如果未设置，身份字段将用于未加密和受保护的领域。

此字段也可用于EAP-SIM / AKA / AKA'上来存储假名身份。

 

字面意思理解就是未加密的地方起个外号（假名），真正的名字只有身份验证服务器才会知晓，但如果没有假名，那在未加密的地方只能用真名了。这样看来有安全风险。

 

2.1.2 回复补充

我们个人用的手机上常用的eap方法有

• WIFI_EAP_METHOD_PWD
• WIFI_EAP_METHOD_TLS
• WIFI_EAP_METHOD_SIM
• WIFI_EAP_METHOD_AKA
• WIFI_EAP_METHOD_AKA_PRIME
• WIFI_EAP_METHOD_PEAP
• WIFI_EAP_METHOD_TTLS

对照安卓代码看下哪些支持，哪些不支持

WifiConfigController

    /**
     * EAP-PWD valid fields include
     *   identity
     *   password
     * EAP-PEAP valid fields include
     *   phase2: MSCHAPV2, GTC, SIM, AKA, AKA'
     *   ca_cert
     *   identity
     *   anonymous_identity
     *   password (not required for SIM, AKA, AKA')
     * EAP-TLS valid fields include
     *   user_cert
     *   ca_cert
     *   domain
     *   identity
     * EAP-TTLS valid fields include
     *   phase2: PAP, MSCHAP, MSCHAPV2, GTC
     *   ca_cert
     *   identity
     *   anonymous_identity
     *   password
     */
    private void showEapFieldsByMethod(int eapMethod) {

从界面上来看

“匿名身份”隐藏

WIFI_EAP_METHOD_PWD

WIFI_EAP_METHOD_TLS

WIFI_EAP_METHOD_SIM

WIFI_EAP_METHOD_AKA

WIFI_EAP_METHOD_AKA_PRIME

 

“匿名身份”显示

WIFI_EAP_METHOD_PEAP

WIFI_EAP_METHOD_TTLS

 

结合上面supplicant的注释，支持“匿名身份”的UI不一定显示，但显示的肯定支持“匿名身份”。

总结说来，EAP-SIM / AKA / AKA'/PEAP/TTLS都支持“匿名身份”。

 

2.2 回答二

What is “anonymous identity” in enterprise WPA?

Nearly all EAP methods in use for 802.1X with WPA/WPA2 wireless authentication utilize an "outer" authentication method simply to establish a TLS tunnel between the client and the authentication server (i.e. a RADIUS server) and an "inner" authentication to provide actual credentials through the secure TLS tunnel.

The "anonymous identity" is used for the outer authentication process and does not need to match the credentials provided in the inner authentication, although if no anonymous identity is provided, the default is to user the inner identity (aka username) for both.

Who get to see this identity ?

This depends. Since the outer authentication is not protected by any sort of encryption anything that can see/process the outer authentication. This list contains some (but not necessarily all) of the things that can possibly see the outer identity:

• Devices near the client that can "hear" and capture the outer authentication
• The NAS (device that forwards traffic associated with the authentication between the client and RADIUS server) which is typically the AP or wireless controller
• The RADIUS server providing authentication (which actually has access to both outer and inner identities)
• Intermediate RADIUS servers if the first RADIUS server proxies the request to other RADIUS servers
• Any device forming the network path between NAS and RADIUS server or between RADIUS servers (when authentications are proxied) - if the path extends outside the locally controlled network, this may include devices on the Internet or controlled by some third party
• Any system that either has access to data on the above or that the above export data to

What is obfuscated by this anonymous identity ?

As already noted, use of the anonymous identity prevents the default action of using the inner identity for the outer identity as well. What exactly is obfuscated will depend on the OS/EAP supplicant and needs of the authentication process in use.

Specifically, you should always be able to obfuscate [at least part of] the username.

For some EAP supplicants, you can substitute both a different username and domain/realm. For others (Window's native EAP supplicant for one), you may only be able to substitute the username.

Any requirements of the authentication process will also determine what can be obfuscated. For example, if the RADIUS server uses the domain/realm in handling the authentication, you may be required to maintain the domain/realm even if your OS allows you to change it. Or, a RADIUS server could use regex matching on the username to determine how to handle the outer authentication (example: usernames containing xxx are handled locally, others are proxied to another RADIUS server), so your anonymous identity would possibly have to maintain at least the part of the username if it needed to match the regex.

回答二讲的很不错了。

1）首先介绍了匿名身份的用途来解释匿名身份 是什么。

几乎所有用于802.1X和WPA / WPA2无线认证的EAP方法都使用“外部”认证方法，只是为了在客户端和认证服务器（即RADIUS服务器）之间建立TLS隧道，并提供实际的“内部”认证通过安全TLS隧道的凭据。

“匿名身份”用于外部身份验证过程，并且不需要匹配内部身份验证中提供的凭据，但如果未提供匿名身份，则默认为用户使用内部身份（也称为用户名）。

2）接着讲了谁会看到这个匿名身份。

由于外部身份验证不受任何可以查看/处理外部身份验证的加密保护，所以这得看情况。此列表包含一些（但不一定是全部）可能看到外部标识的内容：

• 客户端附近可以“听到”并捕获外部身份验证的设备
• NAS（转发客户端和RADIUS服务器之间的身份验证相关流量的设备），通常是AP或无线控制器
• 提供身份验证的RADIUS服务器（实际上可以访问外部和内部身份）
• 中间RADIUS服务器，如果第一个RADIUS服务器将请求代理到其他RADIUS服务器
• 在NAS和RADIUS服务器之间或RADIUS服务器之间形成网络路径的任何设备（当身份验证被代理时） - 如果路径扩展到本地控制的网络之外，这可能包括Internet上的设备或由某些第三方控制的设备
• 任何有权访问上述数据或上述导出数据的系统

3）既然有匿名身份，那用途肯定是用来混淆的，那什么被这个匿名身份混淆了？

如前所述，使用匿名身份也可以防止对外部身份使用内部身份的默认操作。混淆什么则将取决于OS / EAP请求者和正在使用的身份验证过程的需求。

具体来说，您应始终能够混淆[至少部分]用户名。

对于某些EAP请求者，您可以替换不同的用户名和域/域。对于其他人（Window的本机EAP请求者），您可能只能替换用户名。

身份验证过程的任何要求也将决定可以进行模糊处理的内容。例如，如果RADIUS服务器在处理身份验证时使用domain/realm，则可能需要保持domain/realm，即使您的操作系统允许您更改它。或者，RADIUS服务器可以使用用户名上的正则表达式匹配来确定如何处理外部身份验证（例如：包含xxx的用户名在本地处理，其他用户代理到另一个RADIUS服务器），因此您的匿名身份可能必须至少保持匹配正则表达式的用户名的一部分。

这边的讲述让我豁然开朗匿名身份的用途了，匿名身份虽然称作匿名身份，但不是说可以乱取的，这样会混淆所有鉴权服务器。能混淆取决于验证需求，比如验证只关注匿名身份的某些值，那其他值就可以起别名来混淆。举个例子，洛天依达拉崩吧的主角叫做“达拉崩吧斑得贝迪卜多比鲁翁”，那其实知道这个主角的人听到“达拉崩吧斑得”就知道是这首歌的主角了，不知道的人就不知道，那我们说这个主角的名字的时候可以是“达拉崩吧斑得”+xxxxxx。再举个例子，谍战片对暗号的时候肯定都是用的假身份，暗号才是他们包含的真正信息，所以它们的名字可以是任意的+暗号，暗号对上就是自己人了，可以进行真正秘密的交流了。

 

 

2.3 回答三

From documentation (just an example of configuration):

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
    ssid="example"
    scan_ssid=1
    key_mgmt=WPA-EAP
    eap=TTLS
    identity="user@example.com"
    anonymous_identity="anonymous@example.com"
    password="foobar"
    ca_cert="/etc/cert/ca.pem"
    phase2="auth=MD5"
}

It is your identity that is hiden because (your REAL identity) is sent only through an encrypted TLS tunnel.

There are three entries:

• anonymous_identity="fake_identity@something.com"
• identity="username"
• password="password"

You can see your anonymous identity represented by the string used in anonymous_identityparameter is sent unencrypted, whereas your real identity (username, password) are sent only encrypted and no one sees them.

这个回答重复了回答二的部分，匿名身份是不加密传达的，会被很多设备监听到，真正的身份会被加密发送的，只有鉴权服务器才能看到。

 

3.总结

几乎所有用于802.1X和WPA / WPA2无线认证的EAP方法都使用“外部”认证方法，只是为了在客户端和认证服务器（即RADIUS服务器）之间建立TLS隧道，并在实际的“内部”认证通过安全TLS隧道提供凭据。 “匿名身份”用于外部身份验证过程，并且不需要匹配内部身份验证中提供的凭据，但如果未提供匿名身份，则默认为用户使用内部身份（也称为用户名）。

eap的鉴权流程还不是很清楚，从上面的定义来看匿名身份（anonymous identity）是用来混淆视听的，是不加密的，但应该还是带有些特殊信息，之后在客户端和认证服务器（即RADIUS服务器）之间建立TLS隧道，并在实际的“内部”认证通过安全TLS隧道提供凭据。

PS:

RADIUS

A RADIUS client is a RADIUS-enabled device at the network perimeter that enforces access control for users attempting to access network resources. ARADIUS client can be one of the following: VPN server. Wireless access point. Network access server supporting dial-in modems.

TLS(https://en.wikipedia.org/wiki/Transport_Layer_Security)

Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL),[1] are cryptographic protocols designed to provide communications security over a computer network.[2]Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.

The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications.[2]:3 When secured by TLS, connections between a client (e.g., a web browser) and a server (e.g., wikipedia.org) should have one or more of the following properties:

• The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret that was negotiated at the start of the session (see § TLS handshake). The server and client negotiate the details of which encryption algorithm and cryptographic keys to use before the first byte of data is transmitted (see § Algorithm below). The negotiation of a shared secret is both secure (the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places themselves in the middle of the connection) and reliable (no attacker can modify the communications during the negotiation without being detected).
• The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be made optional, but is generally required for at least one of the parties (typically the server).
• The connection is reliable because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.[2]:3

In addition to the properties above, careful configuration of TLS can provide additional privacy-related properties such as forward secrecy, ensuring that any future disclosure of encryption keys cannot be used to decrypt any TLS communications recorded in the past.[3]

TLS supports many different methods for exchanging keys, encrypting data, and authenticating message integrity (see § Algorithm below). As a result, secure configuration of TLS involves many configurable parameters, and not all choices provide all of the privacy-related properties described in the list above (see the § Key exchange (authentication), § Cipher security, and § Data integrity tables).

Attempts have been made to subvert aspects of the communications security that TLS seeks to provide, and the protocol has been revised several times to address these security threats (see § Security). Developers of web browsers have also revised their products to defend against potential security weaknesses after these were discovered (see TLS/SSL support history of web browsers).[4]

The TLS protocol comprises two layers: the TLS record and the TLS handshake protocols.

TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999 and updated in RFC 5246 (August 2008) and RFC 6176 (March 2011). It builds on the earlier SSL specifications (1994, 1995, 1996) developed by Netscape Communications[5] for adding the HTTPS protocol to their Navigator web browser.