随着众多业务的开展，运营商和用户都需要可靠的认证机制来保证合法的业务使用以及正确的计费。尤其是在3G业务中，很多应用都需要在用户端（例如UE）和应用服务器之间进行双向认证，比如客户端和presence服务器间的通信，客户端申请数字证书时与PKI入口的通信等等。而众多业务如果各自使用自己独立的认证，就会造成屡次更换设备。而且由于许多应用都需要同级别的认证机制，因此有必要定义一种通用认证架构（GAA）。
GAA[1]就是旨在提供一种通用的鉴权机制，既可以用于现有的服务，也可以用于将来的新业务，从而避免为每一种新服务都提供独有的鉴权机制。不同应用的一个通用机制避免了各种机制之间的差异性，从而能以一种一致的方式解决安全认证的问题。
2、GAA介绍
在系统中通常有两种认证机制。一种基于通信实体间的共享秘密，另一种基于公钥的证书。如图1所示。
1）基于实现共享秘密机制
基于通信实体间事先共享秘密机制的有若干个认证协议，常有的包括HTTP Digest和IKE协议。这类认证机制的主要问题在于如何在该事先共享秘密上达成一致。GAA中的GBA部分将描述如何在移动的上下文环境中使用基于认证和密钥协商（AKA）的机制，从而为通信实体提供事先共享秘密。
2）基于公钥证书的认证
除了使用共享秘密认证外，另外一种方法基于非对称密码方法进行认证。该认证方法假设需要认证的实体（通信单方或者双方）拥有一个密钥对（公有和私有）以及相应的数字证书。后者验证该密钥对并绑定到其合法拥有者。众所周知的基于密钥对（公有和私有）的协议包括PGP协议、TLS上的HTTP（后者常用其协议名称HTTPS称呼）。
这类认证方法的主要缺点在于需要PKI，非对称的密钥操作与对称的密钥操作相比，经常需要更多的计算量。GAA中的“用户证书支持”（SSC）部分描述了一个移动运营商如何能够给其用户颁发数字证书（因而提供基本PKI）。
3、GAA的组成
如图1所示，GBA（通用Bootstrapping架构）[2]和证书（Certificates）[3]是GAA的主要构成单元。
1）GBA（Gneric Bootstrapping Architecture）
GBA有两种，2G的GBA和3G的GBA，这里主要描述了3G的GBA。GBA旨在描述如何在移动的上下文环境中，使用基于3GPP AKA[5]的机制为客户端（UE）和应用服务器提供事先共享秘密。随后，该共享秘密能用于认证客户和应用程序服务器之间的通信。
AKA是移动网络所用的一个非常普遍的认证机制。GBA重用AKA机制来逐步实现（bootstrap）应用的安全。如下图所示，GBA引入了一个新的网元BSF，其通过与HSS之间的接口获得用户安全信息和认证信息。UE和BSF之间运行AKA认证机制，并根据运行结果（即加密性密钥CK和完整性密钥IK），在BSF和UE之间产生一个会话密钥。一个应用服务器（NAF）能从BSF获得该会话密钥和签约用户档案（Profile）。通过这种方式，NAF和UE就能拥有一个共享密钥，该共享密钥能为随后的应用提供安全保护，特别是在应用会话开始时认证UE和NAF。而且UE和BSF之间的通信、NAF和BSF之间的通信、BSF和HSS之间的通信独立于具体应用，所以是通用的。
2）证书（Certificates）
如果一个客户想利用非对称加密技术，他需要一个由认证中心（CA）[8]生成的数字证书。该数字证书是将一个公开密钥和其合法拥有者的身份信息绑定在一起，并用来证明该公开密钥的合法性。如果一个移动用户想拥有和使用密钥对（公、私密钥对），该密钥对和证书应被预载，或该移动用户必须有方法生成或获取一个密钥对并自动获得其相应的数字证书。
为自动获得一个数字证书，UE必须向归属运营商的公钥基础结构入口（PKI Portal）发送发送证书请求，该PKI Portal必须认证该证书请求。事实上，证书注册过程，即发放一个证书给用户和在UE和PKI Portal之间的相应通信会话，就是一个移动应用实例，UE和PKI Portal之间需要进行认证（后者相当于一个应用服务器）。此处的认证基于PKI Portal和UE之间的预共享加密，如果该共享秘密没有提前预置，则GBA能用来获得这样一个共享秘密。
一旦移动用户拥有一个（公、私）密钥对和一数字证书，他就能用该证书和相应的密钥对来处理数字签名（如移动电子商务应用）和HTTPS等应用。
4、GBA过程
4.1 网络元素与参考点的功能和要求
1）Bootstrapping服务功能（BSF）
Bootstrapping服务功能（BSF）处于用户的归属网络中。通过Zh接口，BSF可以从HSS获得GBA的用户安全设置（GUSS）；通过Ub接口，和UE利用AKA协议进行相互认证，并且建立会话密钥，这个密钥将应用在UE和NAF之间；通过Zn/Zn接口，BSF可以将该密钥和用户安全设置传递给NAF。
2）NAF
Bootstrapping结束以后，UE和NAF可以通过参考点Ua运行一些应用相关协议，在这些协议里面，消息的认证都是基于在UE和BSF相互认证过程中所产生的会话密钥。
在Bootstrapping前，UE和NAF之间以前没有安全关联。为了通过参考点Zn从BSF获取UE和BSF达成的共享密钥，NAF应该能够定位并且能够与用户归属网络的BSF进行安全的通信。并且，NAF能够根据本地策略设置共享密钥的本地有效情况、检测共享密钥的生存期、以及与UE采取措施来保证GBA中密钥的刷新。
3）D-Proxy
当UE被连接到一个外地网络的NAF时，这个拜访的NAF需要利用NAF网络的D-Proxy与用户的BSF（归属网络的BSF）进行通信。此时，D-Proxy在拜访NAF和用户的归属BSF之间起到代理的作用，必须能够找到用户的归属BSF并且可以通过安全信道与之通信。
4）HSS
所有的用户安全设置，也就是GUSS，都存储在HSS中。一个用户具有多个订阅业务情况下，HSS就会包含一个或者多个GUSS，这些GUSS可以映射到一个或者多个私有身份（比如说IMPI、IMSI）。
而GUSS应该包含应用相关用户安全设置（USS），这些用户安全设置包含着与UICC增强型GBA情况下密钥选择（Ks_ext_NAF还是Ks_int_NAF）、与一个或者多个应用的认证和鉴权信息相关的参数。
5）UE
为了和BSF达成共享密钥，UE必须支持HTTP DIGEST AKA[7]协议，并且能够利用CK和IK，产生在Ua接口上与应用一起使用的密钥资料，以及支持与NAF应用相关的协议，如HTTPS等。
根据终端UICC能力的不同，GBA可以分为GBA_ME和GBA_U。前者密钥的协商和生成都在ME中完成，而后者密钥的协商和生成都在UICC中完成，因此安全性更高。一个支持GBA的ME应该支持GBA_U和GBA_ME两种方式。当采用GBA_U方式时，BSF和UE之间达成的共享密钥有Ks_int_NAF和Ks_ext_NAF两种，并且Ks_int_NAF保存在UICC中，不能泄漏给ME，而Ks_ext_NAF会由UICC发送给ME；当采用GBA_ME方式时，达成的共享密钥为Ks_NAF。
当应用层的客户端在ME中时，Ks_ext_NAF应该被用作共享密钥；当应用层的客户端在UICC中时，Ks_int_NAF应该被用作共享密钥。
4.2 过程
1）初始化
在开始GBA过程之前，UE和NAF必须协商好是否采用GBA。一般是由UE首先向NAF发送请求（不包括任何GBA相关信息）；如果NAF需要使用GBA达成共享密钥，则由NAF返回Bootstrapping初始化信息。
2）Bootstrapping过程
在完成上面初始化步骤后或者UE内的密钥已经过期时，UE开始启动如图4所示的Bootstrapping过程。
①UE向BSF发送HTTP请求。
②通过参考点Zh，BSF从HSS中获得GBA用户的全部安全参数设置和一个认证向量（AV，AV=RAND||AUTN||XRES||CK||IK）。
③BSF通过401消息把随机数RAND和AUTN（不发送CK，IK和XRES）发送给UE。
④UE利用RAND值，计算AUTN值，并与BSF发送过来的AUTN进行比对，如果一致，则成功认证网络；UE还计算出CK、IK和RES。这样，BSF和UE都拥有了密钥IK和CK。
⑤UE发送另一个HTTP请求到BSF，其中包含着摘要AKA响应（使用RES计算出来的）。
⑥BSF将摘要AKA响应，与使用XRES计算出来的进行比对，从而对UE进行鉴权。
⑦如果鉴权成功，BSF通过CK和IK来产生密钥资料Ks。并且根据第三步中的RAND和BSF服务器名进行编码，以NAI的格式来产生B-TID值。（B-TID，能够唯一标识该次Bootstrapping事件，以后NAF可以根据这个值向BSF索取达成的相关密钥Ks_NAF）。
⑧BSF发送200 OK消息到UE通知认证成功，该消息中包含B-TID，以及密钥Ks的生存期。在UE中也根据CK和IK产生密钥资料Ks。
⑨在使用bootstrapped安全关联的过程中，根据该Ks，UE和BSF利用Ks产生密钥资料Ks_NAF，来保证参考点Ua的安全。Ks_NAF根据公式KDF（Ks，“gba-me”，RAND，IMPI，NAF_Id）来计算，在GBA_ME模式中，该计算应该在BSF和UE内的ME执行。
注：BSF应该通过Zh接口从HSS中的用户安全信息中获得IMPI。另外，UE和BSF需要保持NAF名（即NAF_Id）的一致性，保存密钥Ks和相关的B-TID，直到Ks的生存期满或者密钥Ks被更新了。
4.3 安全关联的过程
在GBA完成以后，UE和BSF之间达成了共享密钥Ks。UE也用上一节中的步骤中产生Ks_NAF，然而NAF还并没有获得该密钥的有关信息。为了在UE和NAF之间达成共享密钥以进行通信，还需要如图5所示的步骤：
①UE向NAF发起请求
其中，UE和NAF必须进行协商，是否已经建立起共享密钥（Ks_NAF），如果是，则立刻可以开始安全通信；否则，如果还没有建立共享密钥或者密钥已经过期需要更新，UE需要和BSF发起GBA过程去获得Ks和Ks_NAF。
②NAF通过参考点Zn与BSF开始通信
③BSF收到来自NAF的请求以后，BSF首先验证NAF主机名的有效性。然后根据该已经达成的Ks，和收到的NAF_Id以及其他密钥衍生参数根据上节步骤9计算出Ks_NAF，并和用户安全设置一起发给NAF。
④NAF收到Ks_NAF和可能的用户安全设置后，可以进行本地策略设置。然后，NAF把Ks_NAF应用在参考点Ua上的协议中，继续与UE进行交互。
至此，完成了Bootstrapping的过程。
5、基于UICC的增强型GBA（GBA_U）
如前所述，当采用GBA_U时，密钥的协商和生成都由UICC完成。这种增强型的GBA对UE和BSF都提出了新的要求。
5.1 UE的要求
在参考点Ub上的协议所产生的CK、IK及Ks不能离开UICC。收到ME的请求后，UICC必须通过GBA衍生出bootstrapping密钥Ks，还必须能利用存储在UICC上的Ks衍生出NAF相关密钥Ks_int_NAF以及Ks_ext_NAF。
5.2 BSF的要求
BSF应能支持GBA_U和GBA_ME两种Bootstrapping方式，使用哪一种方式取决于签约信息（即UICC能力）。而BSF应可以从HSS中获得的GBA用户安全设置中获知与GBA相关的UICC能力。
5.3 GBA_U的过程
Bootstrapping的初始化与GBA_ME相同。下面详细的过程只是多加了一个UICC到ME之间的内部接口信息的传递过程，计算MAC的方式略微有所不同，具体请参考[2]。
5.4 使用Bootstrapped安全关联的过程
其过程与GBA_ME相似，差别在于：
①UE和NAF在协商密钥的时候，需要约定好采用Ks_int_NAF还是Ks_ext_NAF。
②如果共享密钥为Ks_ext_NAF，则在UICC完成步骤GBA_U过程中步骤9中的密钥产生后，需要实现与ME之间密钥Ks_ext_NAF的传递。
6、支持用户证书（SSC）
图6展示了用户证书支持的网络模型参考图，其中包括证书发放相关的网络实体及连接它们之间的参考点。PKI Portal的作用相当于前面讲到的NAF。在PKI[9]向UE通过参考点Ua颁发用户证书和运营商CA证书时，应当使用基于Ub接口上的GBA过程得到的共享密钥进行认证。通过Zn接口，PKI可以从BSF处得到该密钥。
在用户证书的发放过程中，UE可能会向PKI Portal请求一个公钥的证书，请求格式是PKCS#10[8]，用来封装公钥和其他属性（即用户名、密钥用途等等）。接收到证书请求之后，根据BSF从HSS得到的特定用户安全设置，以及自己的证书操作策略，PKI Portal对公钥进行验证。如果PKI Portal通过该公钥的认证，它将生成相应的证书，并通过参考点Ua传回UE。
在运营商CA证书的发送过程中，UE可能会请求PKI Portal发送运营商CA的证书。在相应的响应中，PKI Portal将把CA的证书发送给UE。
在发放以上两种证书的过程中，认证、完整性保护以及对通过参考点Ua传送的信息可能进行的加密都是基于UE-BSF之间生成的共享秘钥，即Ks_（ext/int）_NAF。为了叙述方便，在下面的过程中提到Ks_NAF的地方，实际上意味着Ks_（ext/int）_NAF。
7、结束语
本文详细介绍了3GPP推出的通用认证框架GAA的作用、结构和使用的过程。随着日益增多的业务应用，GAA势必能够帮助解决屡次需要更新用户卡来支持新的认证方式的问题。这样，尤其对于中国机卡分离的运营模式下的用户可以配置更为先进的认证方式，而不用经常替换SIM卡，从而节约了很大的成本，并且使得运营更为灵活。所以从这个意义上来说，确实不失为一种值得考虑的通用机制。
8、缩略语
9、参考文献
[1] 3GPP TR 33.919:“3rd Generation Partnership Project； Technical Specification Group Services and System Aspects； Generic Authentication Architecture (GAA)；System description”.
[2] 3GPP TS 33.220:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Generic bootstrapping architecture”.
[3] 3GPP TS 33.221:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Support for subscriber certificates”.
[4] 3GPP TS 33.222:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Access to network application functions using secure hypertext transfer protocol (HTTPS)”
[5] 3GPP TS 33.102:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Security architecture”.
[6] IETF RFC 3310 (2002):“Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)”
[7] IETF RFC 2617 (1999):“Franks J,et al”,“ HTTP Authentication: Basic and Digest Access Authentication”,RFC? 2617, June 1999.
[8] PKCS#10:“Certification Request Syntax Standard”.
[9] OMA:“Wireless Identity Module；Part: Security”.
