A-key计算原理，希望高手能试试

闷声色狼

TD-SCDMA系统终端完整性保护方案  
1终端安全特性的实现概述
    在TD-SCDMA系统中，终端接入网的安全性能主要有三个方面的措施：用户鉴权、数据完整性保护和数据加密。终端安全特性的启动是由网络通知的。其中，鉴权过程是在非接入层的MM或GMM实现，用于确定用户的合法性，同时产生接入层完整性保护和加密所需要的密钥。数据加密分为语音业务的加密和数据业务的加密，语音业务的加密由MAC层进行加密，数据业务由RLC层完成。数据完整性保护过程采用F9算法，加密过程使用F8算法。数据的完整性保护过程主要是在RRC子层完成，用于确保信令数据发送和接收的正确性。本文将详细介绍实现数据完整性保护的过程。
2 u1 P% r6 N- b3 M
& S0 j, Y. ]- x" P1 z4 O    2终端完整性保护过程分析


图1
! c; a4 |) C4 {2 b
4 @7 B& I5 N- L2 S) P3 I) T    终端进行完整性保护和加密的过程是由网络来启动的，具体过程如图1所示。网络发送SECURITYMODECOMMAND层3消息要求RRC子层开始消息完整性保护过程。终端的RRC子层在收到SECURITYMODE COMMAND消息之后，解析消息的内容，发送SECURITY MODE COMPLETE消息响应网络。
1 b5 _7 }5 h# U% {& j0 V7 H$ ]
    SECURITYMODECOM-MAND消息包括安全能力单元、完整性保护信息单元、加密信息单元、域信息单元等消息单元。其中，完整性保护信息单元用于启动或修改RRC子层的完整性保护过程；域信息单元用于指定进行完整性保护的域，包括电路交换(CS)域或分组交换(PS)域，在选择完整性保护的密钥时需要使用该参数，详见后续描述。

    3完整性保护过程在RRC子层的实现

    (1)完整性保护过程概述

9 c5 K& J2 K7 t" p& B    RRC子层在收到SECU-RITYMODECOMMAND消息后，解析消息中的完整性保护信息单元来启动完整性保护过程。在完整性消息单元中包含了完整性保护的算法指示及用于完整性保护的其他参数。

+ {  s, l# H  F9 S2 j  `1 H    完整性保护采用的F9算法如图2所示。


图2

    F9算法的入口参数介绍如下。

    IK：完整性保护密钥。由MM层或GMM子层在鉴权过程中产生。如果没有鉴权过程的情况下，密钥是开机的时候由USIM存储的上一次关机时保存的密钥，密钥由MM层发送到RRC层并保存。CS域和PS域各有一个IK，RRC此次选择的是SECURITYMODECOMMAND消息中，域信息单元所指定域的IK来进行完整性保护。

    FRESH：SECURITYMODECOMMAND消息携带的随机数。
3 u- b" U5 h- O; ]" G
    DIRECTION：完整性保护的方向。下行使用DIRECTION等于1，上行使用0。

    MESSAGE：发送的消息内容，包括了消息的长度指示。

, H( C) c+ i  D
图3

! T4 v: V7 W  X: c. W5 }) J% u, |    COUNT_I：该参数共32bit，由两部分组成，前一部分超帧号RRCHFN有28 bit，后4 bit为RRC子层消息序列号（RRC SN）,如图3所示。每个信令SRB分别有一个上行的COUNT_I和下行COUNT_I,分别用于上下行完整性保护。该参数是RRC子层在收到SECURITY MODE COMMAND消息后初始化的。当RRC子层第一次收到SECURITY MODE COMMAND消息后，根据是否进行鉴权即是否收到新的IK，RRC将COUNT_I的HFN部分初始化为0或START值，同时RRC子层初始化上行RRC SN为0，这样确定了上行COUNT_I的初始值。上行每发送一条RRC消息，消息序列号增加1，消息序列号为4 bit，因此最大消息序列号为15，每发送15条为一个循环，每到一个循环周期HFN加1，确定每条上行消息的COUNT_I值。下行COUNT_I的HFN部分初始化与上行部分相同，只是下行消息的RRC SN是由收到消息的完整性检查单元携带的。当启动完整性保护后，在每个SRB上收到的第一条RRC消息中取出带的RRC SN，用于计算鉴权码，如果收到的消息正确，那么将该RRC SN 赋值给下行COUNT_I的低位,确定下行COUNT_I。

    (2)上行消息完整性保护实现方案
/ P' q" {6 N: r
! T5 @9 K1 }; K) m: g    在启动了完整性保护过程后，RRC在组装发送信令消息时必须增加消息的IntegrityCheckInfoIE信息单元。首先，RRC组装需要发送的消息在组装时，设置需要完整性检查比特为1，预留32位的比特(设置为0)位置给鉴权码(Message Authentication Code)和4比特的RRC SN，之后是需要组装的消息内容。对消息进行ASN编码，编码后得到需要进行完整性保护的消息序列和消息长度。

    RRC进行选择完整性保护的密钥，需要考虑新的完整性保护的激活时间问题。发送的消息的RRCSN等于当前的RRCSN加1，如果大于或等于完整性保护的激活时间（由最近一次SECURITY MODE COMMAND消息携带的），那么使用新的完整性密钥IK，否则使用旧的IK。因为CS域和PS域各有一个IK，我们选择收到的SECURITY MODE COMMNAD消息CN Domain IE所指定域的IK。将消息内容（MESSAGE）、消息长度、IK 、FRESH、COUNT_I、DIRECTION参数送到F9函数，计算出鉴权码，修改已经编码过的消息的ASN数据的第2个比特到第37个比特，其中2到33比特位计算出来的鉴权码，34比特到37比特为消息的RRC SN。这样就完成了消息的完整性保护及编码。按照这个方案避免了对消息进行两次ASN编码，第二次我们只是修改了第一次编码后的ASN数据的前37个比特，简化了消息的组装过程。

+ O8 F- w- n( I    (3)下行消息的完整性保护检查实现方案

4 [9 d0 i1 c) u$ c' u1 |: g* S7 G5 W    下行的完整性保护过程是RRC子层对收到的消息进行完整性检查即对收到消息的鉴权码的检查。如果收到的消息中携带的鉴权码与RRC子层计算出的消息鉴权码不一致，认为收到的消息出错将直接丢弃该消息。下面我们就详细分解一下终端对收到消息的鉴权码计算过程。
& @- |/ T: ~4 {4 `% O/ ?, c/ f; T
    首先取得解ANS编码前的层3消息数据，将其前第2个比特到第33个比特替代为0，第34到37比特替代为RRCSN，构成F9算法的消息流，而对于消息的长度在RLC送消息到RRC子层的参数包含了消息长度。下行消息COUNT_I的确定，首先每次我们收到一条正确的消息，都把该消息的RRCSN保存在一个本地变量中。在下一次收到一条RRC消息时，我们通过消息的ASN解码得到消息中携带的RRCSN，该SN与本地保存的RRC SN比较。如果两个RRC SN 相等，那么就说明消息收到过，直接丢弃该消息；如果收到的RRC SN小于本地的RRC SN ，那么本地保存的 RRC HFN 加1。
: x& f( g, b1 |. ?6 t
8 W7 {8 K1 o1 z7 C% H0 s! D. g    由本地保存的下行HFN和消息中携带的本消息RRCSN确定了下行消息的COUNT_I。上行密钥的选择与上行的相同。下行完整性保护的FRESH值与上行相同。
  L* A7 q' V; G$ n% T2 ^
- N0 {& I- ?8 T6 @) R6 \1 d    我们把确定的消息内容(MESSAGE）、消息长度、完整性保护密钥IK、下行COUNT_I、FRESH、DIRECTION的值输入F9函数，得到UE端RRC子层计算的鉴权码的值，与收到的消息中的鉴权码进行比较，如果两者相同，那么接收收到的消息，否则丢弃收到的消息。
6 a2 p" F- R4 M5 t+ x
    消息完整性保护过程很好地检测出可能由部分消息内容丢失、消息被窃取或消息发送多次而引起的消息错误，避免了终端对错误消息的处理。

    (4)下行非顺序接收消息的完整性检查
( `* i9 D6 Z+ m, q2 t, w
6 A2 U  T) K  w! V9 }# }( V    按照上面描述的方案，可以正确地计算出消息的鉴权码，该方案的关键就是如何正确地选择F9算法的IK和COUNT_I值。在收到消息的RRCSN是顺序的情况下，可以保证方案的正确性；在收到消息的RRCSN不是顺序的情况下，我们在选择完整保护IK时可能发生选错的情况。下面我们考虑两种RRC SN不是顺序的情况的处理。

    第一种情况：假设本地保存的RRCSN为5，新的完整性保护开始的时间为9 。本次RRC 收到的消息RRC SN 为4，那么按照原来的方案判断RRC SN 4小于5的情况下，HFN必须增加1 。但是，也有可能RRC收到消息RRC SN并不是顺序的，这导致我们应该是先收到RRN SN 为4这条消息，而却先收到了RRC SN为5的这条消息，也就是这两条消息的HFN应该是相等的。这样按照我们之前的设计方案计算出来的鉴权码必然与消息中携带的鉴权码不等，导致正确消息的丢弃，这种情况下应该有另外的保护措施。解决方案是每次做HFN 加1的时候我们都采用一个标志记录这个行为，然后按照正常的流程计算鉴权码，当我们发现鉴权失败，检查HFN是否曾经增加过，如果增加过我们把HFN减1 ，重新送入F9函数再计算，计算出来的结果再比较。

+ u; l; I% r0 C    第二种情况：假设本地下行的RRCSN为1，新的安全模式激活时间为6。当前收到消息的RRC SN 为15，那么根据正常的流程发现收到消息的SN 15大于激活时间6，这样我们会选择新的IK，例如之前为完整性的CN域为CS ，重新收到SECURITY MODE COMMAND 的CN域为PS，那么此时我们就会由原来CS 域的IK选择成PS 域的IK进行鉴权码的计算。计算结果发现鉴权码不同，此时可能是由于RRC子层本身在选择IK的时候选错。由于消息的不顺序发送，使得RRC SN为15的消息在RRC SN等于1的之后收到，误认为已经过了新的安全模式的激活时间，选择了新IK。为了防止这种错误，我们在第一计算结果比较错误后进行第二次鉴权码计算，使用旧的IK进行计算，计算出来的结果再与消息中携带的鉴权码进行比较。

    在上面两种特殊的情况中，我们都是采用对消息进行第二次的鉴权码计算，避免了由于网络发送消息RRCSN的非顺序性，引起第一次鉴权码计算错误丢弃消息的情况，保证鉴权码计算的正确性，进一步提高了完整性保护的性能。
, W4 ~! ^+ E- n# H另：在【多多手机网】看到有个A-key计算器的东东，感兴趣的兄弟去看看，早CDMA专区
( x! `$ E/ g1 A- n又看到个读A-key软件，随便发了，会用的兄弟出来说说是什么东东！:)1

[ 本帖最后由 闷声色狼 于 2008-2-23 10:50 编辑 ]

pijiu521

沙发 强 先来一个。
) Y( d# m: J  \: ]( A0 {/ {8 }5 X很佩服楼主的研讨精神
& M9 f4 L7 N0 D% R6 P做手机开发有点儿参考价值吧。
随便问一下楼主，你的akey有解决方案了么？

monkeyfunc

顶一下，虽然看了LZ的东西觉得自己是个文盲了。

CyberVsQ

俄国人写过个 A-Key Calculator  ，不知道是不是真的行啊

闷声色狼

我昨晚下载了A-KEY Calculator 1.0版本，不知道怎么用。
1 P$ b; A* }: w2 e楼上的会用吗？

CyberVsQ

不会用，好像还跟生产厂商有关系似的

闷声色狼

方法：哪位兄弟随便弄个133的号码，能搞定A-key，然后不要说，只把ESM值拿出来，用A-Key Calculator  试试能不能算出来！

闷声色狼

CyberVsQ

试过n个了，算不出來，谁去搞个高版本的试试

闷声色狼

郁闷ING！

卒子

关注此贴

KING

那个A-Key Calculator好像不是计算A-Key的，是计算校验码的吧？

monkeyfunc

关注此贴，让关鉴权的JS去S！！！！！！

laomeng

能搞出akey来就太强了