认证方法、生成信任状的方法及相关装置制造方法
【专利摘要】认证方法、生成信任状的方法及相关装置。其中的认证方法包括：当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应第一用户名的第二信任状；根据第二信任状，确认应用客户端是否通过验证；其中，第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。还公开了相应的生成信任状的方法及应用服务器、CGC。在应用客户端请求登录应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
【专利说明】认证方法、生成信任状的方法及相关装置
【技术领域】
[0001]本发明涉及通信安全【技术领域】，尤其涉及认证方法、生成信任状的方法及相关装置。
【背景技术】
[0002]在第三代合作伙伴项目(The3rdGenerat1n Partnership Project, 3GPP)TS33.220 中介绍了一 种通用自引导架构(Generic Bootstrapping Architecture,GBA)认证机制，如图1所示，首先，用户设备(User Equipment, UE)和自引导功能装置BSF (Bootstrapping Funct1n)执行认证流程,UE和BSF共享密钥Ks和密钥标示符B-TID,在该流程中，BSF从家庭注册用户服务器(Home Subscriber Server，HSS)/归属位置寄存器(Home Locat1n Register, HLR)获取认证向量，然后，UE和某应用服务器(NetworkApplicat1n Funct1n, NAF)执行登录认证流程,具体是安装在UE上的应用客户端如浏览器登录应用服务器，NAF根据该用户的B-TID从BSF获得登录该NAF的密钥Ks_NAFl，UE侧也生成域Ks_NAFl相同的Ks_NAF2，NAF和UE基于相同的Ks_NAFl和Ks_NAF2进行验证，以确定是否通过登录认证。该GBA认证机制中，UE是具有通用集成电路卡(UniversalIntegrated Circuit Card, UICC)的设备，但在UE需要通过个人计算机(PersonalComputer, PC)、平板电脑pad等无UICC卡设备访问运营商网络时,或者用户使用的插卡设备上的应用客户端无法自动获取B-TID、Ks_NAF的情况下，用户需要手工将B_TID/Ks_NAF输入到应用客户端或网页的表单中。B-TID的格式为base64encoded(RAND) @BSF_servers_domain_name,即 “24 个区分大小写的字符或数字 @BSF_servers_domain_name。Ks_NAF 是256比特的二进制比特串。对于用户而言，手工输入B-TID/Ks_NAF非常不方便。
[0003]因此，在应用客户端请求应用服务器的登录认证过程中，如何避免需要用户输入复杂的登录该应用服务器的用户名和信任状已成为目前迫切需要解决的问题。
【发明内容】
[0004]有鉴于此，本发明实施例提供了认证方法、生成信任状的方法及相关装置，用以解决现有技术中存在着的在应用客户端请求应用服务器的登录认证过程中，需要用户输入复杂的登录该应用服务器的用户名和信任状的技术问题。
[0005]第一方面，提供了一种认证方法，包括:
[0006]当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状；
[0007]根据所述第二信任状，确认所述应用客户端是否通过验证；
[0008]其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
[0009]在第一种可能的实现方式中，所述接收到应用客户端的登录请求之后，以及所述查找对应所述第一用户名的第二信任状之前，所述方法还包括:
[0010]若所述登录请求中指示没有有效的所述第一信任状时，指示所述应用客户端从所述CGC获取所述第一信任状，其中，所述CGC与所述应用客户端安装在同一个或不同的终端上。
[0011]结合第一方面或第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述查找对应所述第一用户名的第二信任状，包括:
[0012]在本地查找存储的对应所述第一用户名的第二信任状；或
[0013]从所述BSF获取对应所述第一用户名的第二信任状。
[0014]结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，所述从所述BSF获取对应所述第一用户名的第二信任状，包括:
[0015]向所述BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，以使所述BSF查找对应所述第二用户名的密钥和密钥标示符，根据所述密语、密钥标示符、应用服务器的标识符采用设定算法生成所述第二信任状，其中，所述第二用户名与所述第一用户名关联，其中，所述密钥和密钥标示符为与所述CGC共享的密钥Ks和密钥标示符B-TID ；
[0016]获取所述BSF生成的所述第二信任状。
[0017]结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述第二用户名为国际移动识别号MS1、移动用户国际综合业务数字网号码MSISDN或携带所述IMSI或MSISDN的标识。
[0018]第二方面，提供了一种生成信任状的方法，包括:
[0019]接收应用客户端请求登录的应用服务器的标识符；
[0020]采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；
[0021]其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0022]在第一种可能的实现方式中，所述采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，包括:
[0023]采用下面的算法生成所述第一信任状:
[0024]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF| |B-TID)]}。
[0025]其中，Credential为所述第一信任状，Ks_NAF为根据通用自引导架构GBA流程由所述Ks和所述应用服务器的标识符NAF_ID生成的，Trunc48为截取256位SHA-256值的低48比特，base64encoded为进行BASE64编码。
[0026]结合第二方面或第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述接收应用客户端请求登录的应用服务器的标识符，包括:
[0027]接收用户输入的所述应用服务器的标识符；以及
[0028]所述采用设定算法，将所述应用服务器的标识符、与BSF共享的密钥和密钥标示符生成第一信任状之后，所述方法还包括:
[0029]输出所述第一信任状给所述用户。
[0030]结合第二方面或第二方面的第一种可能的实现方式，在第三种可能的实现方式中，所述接收应用客户端请求登录的应用服务器的标识符，包括:
[0031]接收所述应用客户端的信任状获取请求，所述信任状获取请求包括所述应用服务器的标识符；以及
[0032]所述采用设定算法，将所述应用服务器的标识符、与BSF共享的密钥和密钥标示符生成第一信任状之后，所述方法还包括:
[0033]将所述第一信任状发送给所述应用客户端。
[0034]第三方面，提供了一种应用服务器，包括:
[0035]第一查找单元，用于当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状；
[0036]确认单元，用于根据所述第二信任状，确认所述应用客户端是否通过验证；
[0037]其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
[0038]在第一种可能的实现方式中，所述应用服务器还包括:
[0039]指示单元，用于若所述登录请求中指示没有有效的所述第一信任状时，指示所述应用客户端从所述CGC获取所述第一信任状，其中，所述CGC与所述应用客户端安装在同一个或不同的终端上。
[0040]结合第三方面或第三方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一查找单元包括:
[0041]第二查找单元，用于在本地查找存储的对应所述第一用户名的第二信任状；或
[0042]第一获取单元，用于从所述BSF获取对应所述第一用户名的第二信任状。
[0043]结合第三方面的第二种可能的实现方式，在第三种可能的实现方式中，所述第一获取单元包括:
[0044]第一发送单元，用于向所述BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，以使所述BSF查找对应所述第二用户名的密钥和密钥标示符，根据所述密语、密钥标示符、应用服务器的标识符采用设定算法生成所述第二信任状，其中，所述第二用户名与所述第一用户名关联，其中，所述密钥和密钥标示符为与所述CGC共享的密钥Ks和密钥标示符B-TID ；
[0045]第二获取单元，用于获取所述BSF生成的所述第二信任状。
[0046]结合第三方面的第三种可能的实现方式，在第四种可能的实现方式中，所述第二用户名为国际移动识别号MS1、移动用户国际综合业务数字网号码MSISDN或携带所述IMSI或MSISDN的标识。
[0047]第四方面，提供了一种信任状生成客户端CGC，包括:
[0048]第一接收单元，用于接收应用客户端请求登录的应用服务器的标识符；
[0049]第一生成单元，用于采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；
[0050]其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0051]在第一种可能的实现方式中，所述第一生成单元包括:
[0052]第二生成单元，用于采用下面的算法生成所述第一信任状:
[0053]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF| |B-TID)]}。
[0054]其中，Credential为所述第一信任状，Ks_NAF为根据通用自引导架构GBA流程由所述Ks和所述应用服务器的标识符NAF_ID生成的，Trunc48为截取256位SHA-256值的低48比特，base64encoded为进行BASE64编码。
[0055]结合第四方面或第四方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一接收单元包括:
[0056]第二接收单元，用于接收用户输入的所述应用服务器的标识符；以及
[0057]所述CGC还包括:
[0058]输出单元，用于输出所述第一信任状给所述用户。
[0059]结合第四方面或第四方面的第一种可能的实现方式，在第三种可能的实现方式中，所述第一接收单元包括:
[0060]第三接收单元，用于接收所述应用客户端的信任状获取请求，所述信任状获取请求包括所述应用服务器的标识符；以及
[0061]所述CGC还包括:
[0062]第二发送单元，用于将所述第一信任状发送给所述应用客户端。
[0063]采用本发明的认证方法、生成信任状的方法及相关装置的技术方案，在应用客户端请求登录应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
【专利附图】
【附图说明】
[0064]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0065]图1为现有技术中的通用自引导架构GBA示意图；
[0066]图2为本发明一种认证方法的一个实施例的流程图；
[0067]图3为对图2所示的本发明一种认证方法的实施例的进一步细化的另一个实施例的流程图；
[0068]图4为本发明一种生成信任状的方法的一个实施例的流程图；
[0069]图5为对图4所示的本发明一种生成信任状的方法的实施例的进一步细化的另一个实施例的流程图；
[0070]图6为对图4所示的本发明一种生成信任状的方法的实施例的进一步细化的又一个实施例的流程图；
[0071]图7为本发明一种应用服务器的一个实施例的结构不意图；
[0072]图8为对图7所示的本发明一种应用服务器的实施例的进一步细化的另一个实施例的结构不意图；
[0073]图9为本发明一种信任状生成客户端CGC的一个实施例的结构示意图；
[0074]图10为对图9所示的本发明一种CGC的实施例的进一步细化的另一个实施例的结构示意图；
[0075]图11为对图9所示的本发明一种CGC的实施例的进一步细化的又一个实施例的结构示意图。
【具体实施方式】
[0076]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0077]图2为本发明一种认证方法的一个实施例的流程图。如图2所示，该方法包括以下步骤:
[0078]步骤S101，当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状，其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
[0079]本发明实施例中的应用客户端安装在终端上，该终端可以是有卡的设备，如移动终端，也可以是无nCC卡的设备，如PC、pad等。应用客户端包括微博、微信等OTT (OverThe Top)应用客户端。需要注意的是，浏览器也是一种应用客户端。
[0080]用户想要在应用客户端上登录应用服务器时，用户在应用客户端上输入第一用户名，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式；同时，输入第一信任状，该第一信任状是由应用客户端所在终端或其它终端上设置的信任状生成客户端(Credential Generat1n Client,CGC)生成的。值得说明的是，该第一用户名可以是用户自定义的易记的名称，该第一信任状也是CGC采用特定的算法处理后便于用户记忆的信任状。应用客户端按照和应用服务器之间的认证协议，根据第一信任状和第一用户名生成的登录请求登录应用服务器。
[0081]接收到应用客户端的登录请求时，解析该登录请求，获得第一用户名，根据该第一用户名，获得第一信任状，然后查找对应第一用户名的第二信任状。若用户曾经登录过该应用服务器，应用服务器本地可能存储有该第二信任状，因此，可以在本地查找到对应该第一用户名的由BSF生成的第二信任状；若本地没有存储，则从BSF获取对应该第一用户名的第二任状。
[0082]本发明可以采用任意终端上的CGC，只要是生成对应第一用户名的第一信任状的CGC即可。BSF首先和该CGC执行GBA流程，协商得到相同的B-TID和Ks，该Ks以第一用户名或第一用户名关联的其它标识存储；然后，根据发送信任状获取请求的应用服务器的标识NAF_ID，根据获取请求中的第一用户名或与第一用户名关联的标识查找到相应的Ks，然后采用与CGC生成第一信任状的相同的算法，生成该第二信任状。BSF将生成的第二信任状发送给应用服务器。采用特定的算法使生成的信任状也便于用户输入。
[0083]步骤S102，根据所述第二信任状，确认所述应用客户端是否通过验证。
[0084]比较第一信任状和第二信任状，如果比较的结果一致，则验证成功，允许应用客户端登录，向应用客户端返回登录成功消息。否则，则验证失败，不允许应用客户端登录，向应用客户端返回登录失败消息。
[0085]根据本发明实施例提供的一种认证方法，在应用客户端请求登录应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
[0086]图3为对图2所示的本发明一种认证方法的实施例的进一步细化的另一个实施例的流程图。如图3所示，该方法包括以下步骤:
[0087]步骤S201，接收应用客户端的第一登录请求。
[0088]在本实施例中，应用客户端所在的终端可以为PC、pad等无WCC卡或全球用户识别模块(Universal Subscriber Identity Module, USIM)的设备，因此，该终端无法通过UICC卡与BSF进行通信认证，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过其上的CGC，获取对应该第一用户名的第一信任状。该终端也可以是有nCC卡或USIM卡的设备，应用客户端可以直接发送第一信任状获取请求给该终端上的CGC。
[0089]如果应用客户端能从所在终端获得有效的第一信任状，则该应用客户端根据第一用户名和第一信任状生成该登录请求；否则，应用客户端根据第一用户名生成该登录请求，并在登录请求中携带指示，说明该应用客户端没有有效的第一信任状。该第一用户名是由用户在应用客户端上输入的，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式，是用户自定义的易记的名称。
[0090]步骤S202，查找所述第一登录请求中是否携带指示，说明所述应用客户端没有有效的第一信任状，如果没有携带指示，则转至步骤S205 ;否则，转至步骤S203。
[0091]登录请求若没有携带指示说明应用客户端没有有效的第一信任状，则说明应用客户端有有效的第一信任状，转至步骤S205，继续进行下面的登录认证流程；如果登录请求中指示其没有有效的第一信任状，则转至步骤S203。
[0092]步骤S203，发送所述第一信任状无效的响应消息给所述应用客户端，所述响应消息指示所述应用客户端从信任状生成客户端CGC获取所述第一信任状。
[0093]由于确认登录请求中没有携带有效的第一信任状，该登录认证流程无法继续，发送第一信任状无效的响应消息给应用客户端，在该响应消息中指示或提示应用客户端从CGC获取该第一信任状。例如，指示用户在其插有nCC卡的移动终端的CGC上输入应用服务器的标识NAF_ID等，应用服务器或BSF也可能进一步通过短消息等渠道将相应的应用客户端、终端和应用服务器的信息发送给用户的插有ncc卡的移动终端，以提示用户其正在尝试访问某个应用服务器。
[0094]用户在其插有卡的终端上安装的CGC输入其访问的应用服务器的标识NAF_ID, CGC根据其与BSF共享的B-TID、Ks以及该NAF_ID，按照与BSF约定的算法生成第一信任状。若CGC上没有有效的Ks、B-TID,则CGC需要和BSF执行GBA流程以生成有效的Ks、B-TID0
[0095]步骤S204,接收应用客户端的第二登录请求。
[0096]应用客户端从插有卡的终端上获得对应该第一用户名的第一信任状后，在应用客户端上输入第一信任状，根据第一用户名和第一信任状重新生成登录请求，并重新发送给应用服务器。应用服务器接收应用客户端重新发送的登录请求。
[0097]步骤S205，判断本地是否存储有对应所述第一用户名的第二信任状，如果是，则转至步骤S206 ;否则，转至步骤S207。
[0098]步骤S206，获取在本地存储的对应所述第一用户名的第二信任状。
[0099]如果用户曾以该第一用户名和第一信任状成功登录过该应用服务器，应用服务器本地可能存储有用于验证该用户的登录请求的从BSF获取的第二信任状，应用服务器本地可能还以用户名为标识分类存储有多个用户的信任状，因此，需根据第一用户名查找和获取对应该第一用户名的第二信任状。如果本地没有存储对应该第一用户名的第二信任状，则转至步骤S207，从BSF重新获取该第二信任状。
[0100]步骤S207，向BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，所述第二用户名与所述第一用户名关联。
[0101]步骤S208，获取所述BSF生成的所述第二信任状。
[0102]首先，将从应用客户端接收到的登录请求中携带的第一用户名转换成BSF能识别的第二用户名，如国际移动用户识别码(Internat1nal Mobile SubscriberIndentificat1n Number, IMSI)或移动注册用户国际综合业务数字网号码(MobileSubscriber Internat1nal ISDN/PSTN number，MSISDN)，或包含 MSI 或 MSISDN 信息的身份标识，这是由于BSF只能识别MSI或MSISDN。该第二用户名用于在BSF上查找Ks和B-TID。然后，向BSF发送该第二信任状的获取请求，BSF首先根据该第二用户名查找到对应的Ks，该Ks是BSF和生成第一信任状的CGC通过执行GBA流程共享的，根据与该CGC约定的算法，将Ks、B-TID和发送该获取请求的应用服务器的NAF_ID生成第二信任状，并返回给应用服务器。
[0103]一种信任状(Credential)的生成方法为:
[0104]Ks_NAF=KDF(Ks, NAF_ID)；
[0105]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF B-TID)]}。
[0106]g卩，CGC先根据TS33.220中的方法生成Ks_NAF，然后计算Ks | B-TID的SHA-256值。截取256位SHA-256值的低48比特进行BASE64编码，最后输出为8位区分大小写的英文字符或数字。生成的信任状为用户容易输入的信任状。
[0107]步骤S209，根据所述第二信任状，确认所述应用客户端是否通过验证。如果是，则转至步骤S210 ;否则，转至步骤S211。
[0108]比较第一信任状和第二信任状是否一致，若是，则验证成功，如果不一致，则验证失败。
[0109]步骤S210，向所述应用客户端返回登录成功消息。
[0110]步骤S211，向所述应用客户端返回登录失败消息。
[0111]如果验证通过，则向应用客户端返回登录成功消息；如果验证失败，则向应用客户端返回登录失败消息。
[0112]根据本发明实施例提供的一种认证方法，在应用客户端请求登录应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
[0113]图4为本发明一种生成信任状的方法的一个实施例的流程图。如图4所示，该方法包括以下步骤:
[0114]步骤S301，接收应用客户端请求登录的应用服务器的标识符。
[0115]本发明实施例中的应用客户端安装在终端上，该终端可以是有卡的设备，如移动终端，也可以是无ΠCC卡的设备，如PC、pad等，应用客户端包括微博、微信等OTT (OverThe Top)应用客户端。需要注意的是，浏览器也是一种应用客户端。
[0116]当应用客户端请求登录某应用服务器时，接收该应用客户端发送的或者用户直接输入的该应用服务器的标识符NAF_ID。
[0117]步骤S302，采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0118]用户想要在应用客户端上登录应用服务器时，用户在应用客户端上输入第一用户名，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式；同时，输入第一信任状，该第一信任状是由应用客户端所在终端或其它终端上设置的CGC生成的。值得说明的是，该第一用户名可以是用户自定义的易记的名称，该第一信任状也是CGC采用特定的算法处理后便于用户记忆的信任状。应用客户端根据第一用户名和第一信任状生成的登录请求，根据该登录请求请求应用服务器的验证。
[0119]如果应用客户端所在的终端为PC、pad等无卡或USM的设备，因此，该终端无法通过ncc卡与BSF进行通信认证，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过该终端上的CGC，获取对应该第一用户名的第一信任状。该终端也可以是有UICC卡或USIM卡的设备，应用客户端可以直接发送第一信任状获取请求给该终端上的CGC。
[0120]CGC首先与BSF执行GBA流程，以获得共享的B-TID和Ks ;然后，根据接收到的NAF_ID，采用与BSF约定的算法生成第一信任状。一种信任状(Credential)的生成方法为:
[0121]Ks_NAF=KDF(Ks, NAF_ID)；
[0122]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF| |B-TID)]}。
[0123]g卩，CGC先根据TS33.220中的方法生成Ks_NAF，然后计算Ks | B-TID的SHA-256值。截取256位SHA-256值的低48比特进行BASE64编码，最后输出为8位区分大小写的英文字符或数字。生成的信任状为用户容易输入的信任状。
[0124]BSF在与CGC执行GBA流程时，根据第一信任状关联的第一用户名，或采用第一用户名关联的其它标识，对应存储了该第一用户名或标识的Ks和B-TID。当应用服务器接收到应用客户端的登录请求时，应用服务器获取登录请求中的第一用户名，根据该用户名向BSF发送第二信任状获取请求，BSF根据该获取请求携带的第一用户名或与第一用户名关联的其它标识查找到对应的Ks，根据与CGC生成第一信任状相同的方式，生成第二信任状并返回给应用服务器，以使应用服务器对该登录请求进行验证。
[0125]根据本发明实施例提供的生成信任状的方法，采用与BSF相同的方式生成登录任一服务器的信任状，可以为任意终端上的应用客户端提供登录该应用服务器的信任状，生成的信任状方便用户输入。
[0126]图5为对图4所示的本发明一种生成信任状的方法的实施例的进一步细化的另一个实施例的流程图。如图5所示，该方法包括以下步骤:
[0127]步骤S401，接收用户输入的应用客户端请求登录的应用服务器的标识符。
[0128]本实施例中，应用客户端所在的终端为PC、pad等无卡或USM的设备，因此，该终端无法通过ncc卡与BSF进行通信认证，没有设置CGC，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过其上的CGC，获取对应该第一用户名的第一信任状。
[0129]因此，需要用户在该CGC上输入需要登录的应用服务器的标识符。输入方式可以手工输入，也可以在CGC上预设置多个应用服务器的NAF_ID，用户点选对应的应用服务器即可。
[0130]步骤S402，采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状和所述第一信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0131]步骤S402与前述实施例的步骤S302相同，在此不再赘述。
[0132]步骤S403，输出所述第一信任状给所述用户。
[0133]CGC根据B-TID、Ks和NAF_ID生成第一信任状，并将第一信任状在终端屏幕上显示给用户，以供用户将该第一信任状输入另一终端的应用客户端，以使该应用客户端根据该第一信任状和第一用户名生成登录请求，将该登录请求发送给应用服务器以请求验证。
[0134]根据本发明实施例提供的生成信任状的方法，采用与BSF相同的方式生成登录任一服务器的信任状，可以为无法执行GBA流程的终端上的应用客户端提供登录该应用服务器的信任状，生成的信任状方便用户输入。
[0135]图6为对图4所示的本发明一种生成信任状的方法的实施例的进一步细化的又一个实施例的流程图。如图6所示，该方法包括以下步骤:
[0136]步骤S501，接收应用客户端的信任状获取请求，所述信任状获取请求包括所述应用客户端请求登录的应用服务器的标识符。
[0137]本实施例中，应用客户端所在的终端为有ΠCC卡或USM卡的设备，可以与BSF执行GBA流程。因此，直接本终端的应用客户端发送的信任状获取请求，该请求中包括应用客户端请求登录的应用服务器的标识。
[0138]步骤S502，采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0139]步骤S502与前述实施例的步骤S302相同，在此不再赘述。
[0140]步骤S503，将所述第一信任状发送给所述应用客户端。
[0141]CGC根据B-TID、Ks和NAF_ID生成第一信任状后，将该第一信任状直接发送给应用客户端，以使该应用客户端根据该第一信任状和第一用户名生成登录请求，将该登录请求发送给应用服务器以请求验证。
[0142]根据本发明实施例提供的生成信任状的方法，可以直接接收本终端的应用客户端的信任状获取请求，采用与BSF相同的方式生成登录任一服务器的信任状，无需用户输入该信任状，方便应用服务器的登录。
[0143]图7为本发明一种应用服务器的一个实施例的结构示意图。如图7所示，该应用服务器1000包括:
[0144]第一查找单元11，用于当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状，其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
[0145]本发明实施例中的应用客户端安装在终端上，该终端可以是有卡的设备，如移动终端，也可以是无ncc卡的设备，如PC、pad等。应用客户端包括微博、微信等OTT (OverThe Top)应用客户端。需要注意的是，浏览器也是一种应用客户端。
[0146]用户想要在应用客户端上登录应用服务器时，用户在应用客户端上输入第一用户名，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式；同时，输入第一信任状，该第一信任状是由应用客户端所在终端或其它终端上设置的信任状生成客户端(Credential Generat1n Client,CGC)生成的。值得说明的是，该第一用户名可以是用户自定义的易记的名称，该第一信任状也是CGC采用特定的算法处理后便于用户记忆的信任状。应用客户端按照和应用服务器之间的认证协议，根据第一信任状和第一用户名生成的登录请求登录应用服务器。
[0147]接收到应用客户端的登录请求时，解析该登录请求，获得第一用户名，根据该第一用户名，获得第一信任状，然后第一查找单元11查找对应第一用户名的第二信任状。若用户曾经登录过该应用服务器，应用服务器本地可能存储有该第二信任状，因此，可以在本地查找到对应该第一用户名的由BSF生成的第二信任状；若本地没有存储，则从BSF获取对应该第一用户名的第二信任状。
[0148]本发明可以采用任意终端上的CGC，只要是生成对应第一用户名的第一信任状的CGC即可。BSF首先和该CGC执行GBA流程，协商得到相同的B-TID和Ks，该Ks以第一用户名或第一用户名关联的其它标识存储；然后，根据发送信任状获取请求的应用服务器的标识NAF_ID，根据获取请求中的第一用户名或与第一用户名关联的标识查找到相应的Ks，然后采用与CGC生成第一信任状的相同的算法，生成该第二信任状。BSF将生成的第二信任状发送给应用服务器。采用特定的算法使生成的信任状也便于用户输入。
[0149]确认单元12，用于根据所述第二信任状，确认所述应用客户端是否通过验证。
[0150]比较第一信任状和第二信任状，如果比较的结果一致，则确认单元12确认验证成功，允许应用客户端登录，向应用客户端返回登录成功消息。否则，则确认单元12确认验证失败，不允许应用客户端登录，向应用客户端返回登录失败消息。
[0151]根据本发明实施例提供的一种应用服务器，在应用客户端请求登录该应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
[0152]图8为对图7所示的本发明一种应用服务器的实施例的进一步细化的另一个实施例的结构示意图。如图8所示，该应用服务器2000包括:
[0153]指示单元21，用于若所述登录请求中指示没有有效的所述第一信任状时，指示所述应用客户端从所述CGC获取所述第一信任状，其中，所述CGC与所述应用客户端安装在同一个或不同的终端上。
[0154]在本实施例中，应用客户端所在的终端可以为PC、pad等无HCC卡或全球用户识别模块(Universal Subscriber Identity Module, USIM)的设备，因此，该终端无法通过UICC卡与BSF进行通信认证，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过其上的CGC，获取对应该第一用户名的第一信任状。该终端也可以是有nCC卡或USIM卡的设备，应用客户端可以直接发送第一信任状获取请求给该终端上的CGC。
[0155]如果应用客户端能从所在终端获得有效的第一信任状，则该应用客户端根据第一用户名和第一信任状生成该登录请求；否则，应用客户端根据第一用户名生成该登录请求，并在登录请求中携带指示，说明该应用客户端没有有效的第一信任状。该第一用户名是由用户在应用客户端上输入的，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式，是用户自定义的易记的名称。
[0156]登录请求若没有携带指示说明应用客户端没有有效的第一信任状，则说明应用客户端有有效的第一信任状，则继续进行登录认证；如果登录请求中指示其没有有效的第一信任状，则指示单元21指示应用客户端从CGC获取第一信任状。
[0157]由于确认登录请求中没有携带有效的第一信任状，该登录认证流程无法继续，指示单元21发送第一信任状无效的响应消息给应用客户端,在该响应消息中指示或提示应用客户端从CGC获取该第一信任状。例如，指示用户在其插有UICC卡的移动终端的CGC上输入应用服务器的标识NAF_ID等，应用服务器或BSF也可能进一步通过短消息等渠道将相应的应用客户端、终端和应用服务器的信息发送给用户的插有ncc卡的移动终端，以提示用户其正在尝试访问某个应用服务器。
[0158]用户在其插有卡的终端上安装的CGC输入其访问的应用服务器的标识NAF_ID, CGC根据其与BSF共享的B-TID、Ks以及该NAF_ID，按照与BSF约定的算法生成第一信任状。若CGC上没有有效的Ks、B-TID,则CGC需要和BSF执行GBA流程以生成有效的Ks、B-TID0
[0159]应用客户端从插有卡的终端上获得对应该第一用户名的第一信任状后，在应用客户端上输入第一信任状，根据第一用户名和第一信任状重新生成登录请求，并重新发送给应用服务器。应用服务器接收应用客户端重新发送的登录请求。
[0160]第一查找单元22，用于当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状。
[0161]在本实施例中，第一查找单元22包括第二查找单元221和第一获取单元222。
[0162]第二查找单元221，用于在本地查找存储的对应所述第一用户名的第二信任状。
[0163]第一获取单元222，用于从所述BSF获取对应所述第一用户名的第二信任状。
[0164]如果用户曾以该第一用户名和第一信任状成功登录过该应用服务器，应用服务器本地可能存储有用于验证该用户的登录请求的从BSF获取的第二信任状，应用服务器本地可能还以用户名为标识分类存储有多个用户的信任状，因此，第二查找单元221根据第一用户名查找和获取对应该第一用户名的第二信任状。如果本地没有存储对应该第一用户名的第二信任状，则由第一获取单元222从BSF重新获取该第二信任状。
[0165]其中，第一获取单元222又包括第一发送单元00和第二获取单元01。
[0166]第一发送单元00，用于向所述BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，以使所述BSF查找对应所述第二用户名的密钥和密钥标示符，根据所述密语、密钥标示符、应用服务器的标识符采用设定算法生成所述第二信任状，其中，所述第二用户名与所述第一用户名关联，其中，所述密钥和密钥标示符为与所述CGC共享的密钥Ks和密钥标示符B-TID。
[0167]第二获取单元01，用于获取所述BSF生成的所述第二信任状。
[0168]首先，将从应用客户端接收到的登录请求中携带的第一用户名转换成BSF能识别的第二用户名，如国际移动用户识别码(Internat1nal Mobile SubscriberIndentificat1n Number, IMSI)或移动注册用户国际综合业务数字网号码(MobileSubscriber Internat1nal ISDN/PSTN number，MSISDN)，或包含 MSI 或 MSISDN 信息的身份标识，这是由于BSF只能识别MSI或MSISDN。该第二用户名用于在BSF上查找Ks和B-TID。然后，向BSF发送该第二信任状的获取请求，BSF首先根据该第二用户名查找到对应的Ks，该Ks是BSF和生成第一信任状的CGC通过执行GBA流程共享的，根据与该CGC约定的算法，将Ks、B-TID和发送该获取请求的应用服务器的NAF_ID生成第二信任状，并返回给应用服务器。
[0169]—种信任状(Credential)的生成方法为:
[0170]Ks_NAF=KDF (Ks, NAF_ID)；
[0171]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF| |B-TID)]}。
[0172]即，CGC先根据TS33.220中的方法生成Ks_NAF，然后计算Ks | | B-TID的SHA-256值。截取256位SHA-256值的低48比特进行BASE64编码，最后输出为8位区分大小写的英文字符或数字。生成的信任状为用户容易输入的信任状。
[0173]确认单元23，用于根据所述第二信任状，确认所述应用客户端是否通过验证。
[0174]比较第一信任状和第二信任状是否一致，若是，则验证成功，如果不一致，则验证失败。
[0175]如果验证通过，则向应用客户端返回登录成功消息；如果验证失败，则向应用客户端返回登录失败消息。
[0176]根据本发明实施例提供的一种应用服务器，在应用客户端请求登录该应用服务器时，可以输入用户易记的用户名，并输入任一终端上的CGC与BSF采用相同的方式生成的容易输入的信任状，通过该用户名和信任状完成应用服务器的登录认证，避免用户输入复杂的用户名和信任状，简化了该登录过程。
[0177]图9为本发明一种信任状生成客户端CGC的一个实施例的结构示意图。如图9所示，该CGC3000包括:
[0178]第一接收单元31，用于接收应用客户端请求登录的应用服务器的标识符。
[0179]本发明实施例中的应用客户端安装在终端上，该终端可以是有卡的设备，如移动终端，也可以是无ΠCC卡的设备，如PC、pad等，应用客户端包括微博、微信等OTT (OverThe Top)应用客户端。需要注意的是，浏览器也是一种应用客户端。
[0180]当应用客户端请求登录某应用服务器时，第一接收单元31接收该应用客户端发送的或者用户直接输入的该应用服务器的标识符NAF_ID。
[0181]第一生成单元32，用于采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0182]用户想要在应用客户端上登录应用服务器时，用户在应用客户端上输入第一用户名，该第一用户名可以是用户的手机号码，也可以是用户在应用服务器上注册的账号等格式；同时，输入第一信任状，该第一信任状是由应用客户端所在终端或其它终端上设置的CGC生成的。值得说明的是，该第一用户名可以是用户自定义的易记的名称，该第一信任状也是CGC采用特定的算法处理后便于用户记忆的信任状。应用客户端根据第一用户名和第一信任状生成的登录请求，根据该登录请求请求应用服务器的验证。
[0183]如果应用客户端所在的终端为PC、pad等无WCC卡或USM的设备，因此，该终端无法通过ncc卡与BSF进行通信认证，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过该终端上的CGC，获取对应该第一用户名的第一信任状。该终端也可以是有UICC卡或USIM卡的设备，应用客户端可以直接发送第一信任状获取请求给该终端上的CGC。
[0184]CGC首先与BSF执行GBA流程，以获得共享的B-TID和Ks ;然后，根据接收到的NAF_ID，采用与BSF约定的算法生成第一信任状。一种信任状(Credential)的生成方法为:
[0185]Ks_NAF=KDF (Ks, NAF_ID)；
[0186]Credential=base64encoded{Trunc48[SHA-256(Ks_NAF| |B-TID)]}。
[0187]g卩，CGC先根据TS33.220中的方法生成Ks_NAF，然后计算Ks | B-TID的SHA-256值。截取256位SHA-256值的低48比特进行BASE64编码，最后输出为8位区分大小写的英文字符或数字。生成的信任状为用户容易输入的信任状。
[0188]BSF在与CGC执行GBA流程时，根据第一信任状关联的第一用户名，或采用第一用户名关联的其它标识，对应存储了该第一用户名或标识的Ks和B-TID。当应用服务器接收到应用客户端的登录请求时，应用服务器获取登录请求中的第一用户名，根据该用户名向BSF发送第二信任状获取请求，BSF根据该获取请求携带的第一用户名或与第一用户名关联的其它标识查找到对应的Ks，根据与CGC生成第一信任状相同的方式，生成第二信任状并返回给应用服务器，以使应用服务器对该登录请求进行验证。
[0189]根据本发明实施例提供的CGC，采用与BSF相同的方式生成登录任一服务器的信任状，可以为任意终端上的应用客户端提供登录该应用服务器的信任状，生成的信任状方便用户输入。
[0190]图10为对图9所示的本发明一种CGC的实施例的进一步细化的另一个实施例的结构示意图。如图10所示，该CGC4000:
[0191]第二接收单元41，用于接收用户输入的应用客户端请求登录的应用服务器的标识符。
[0192]本实施例中，应用客户端所在的终端为PC、pad等无卡或USM的设备，因此，该终端无法通过ncc卡与BSF进行通信认证，没有设置CGC，无法与BSF共享相同的B-TID和Ks，虽然该终端没有CGC，但可以借助其它具有nCC卡的终端，通过其上的CGC，获取对应该第一用户名的第一信任状。
[0193]因此，需要用户在该CGC上输入需要登录的应用服务器的标识符。输入方式可以手工输入，也可以在CGC上预设置多个应用服务器的NAF_ID，用户点选对应的应用服务器即可。
[0194]第一生成单元42，用于采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0195]第一生成单元42的功能与前述实施例的第一生成单元32相同，在此不再赘述。
[0196]输出单元43，用于输出所述第一信任状给所述用户。
[0197]CGC根据B-TID、Ks和NAF_ID生成第一信任状，并将第一信任状在终端屏幕上显示给用户，以供用户将该第一信任状输入另一终端的应用客户端，以使该应用客户端根据该第一信任状和第一用户名生成登录请求，将该登录请求发送给应用服务器以请求验证。
[0198]根据本发明实施例提供的CGC，采用与BSF相同的方式生成登录任一服务器的信任状，可以为无法执行GBA流程的终端上的应用客户端提供登录该应用服务器的信任状，生成的信任状方便用户输入。
[0199]图11为对图9所示的本发明一种CGC的实施例的进一步细化的又一个实施例的结构示意图。如图11所示，该CGC5000包括:
[0200]第三接收单元51，用于接收应用客户端的信任状获取请求，所述信任状获取请求包括所述应用客户端请求登录的应用服务器的标识符。
[0201]本实施例中，应用客户端所在的终端为有卡或USM卡的设备，可以与BSF执行GBA流程。因此，直接本终端的应用客户端发送的信任状获取请求，该请求中包括应用客户端请求登录的应用服务器的标识。
[0202]第一生成单元52，用于采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
[0203]第一生成单元52的功能与前述实施例的第一生成单元32相同，在此不再赘述。
[0204]第二发送单元53，用于将所述第一信任状发送给所述应用客户端。
[0205]CGC根据B-TID、Ks和NAF_ID生成第一信任状后，将该第一信任状直接发送给应用客户端，以使该应用客户端根据该第一信任状和第一用户名生成登录请求，将该登录请求发送给应用服务器以请求验证。
[0206]根据本发明实施例提供的CGC，可以直接接收本终端的应用客户端的信任状获取请求，采用与BSF相同的方式生成登录任一服务器的信任状，无需用户输入该信任状，方便应用服务器的登录。
[0207]以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。
【权利要求】
1.一种认证方法，其特征在于，包括: 当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状； 根据所述第二信任状，确认所述应用客户端是否通过验证； 其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
2.如权利要求1所述的方法，其特征在于，所述接收到应用客户端的登录请求之后，以及所述查找对应所述第一用户名的第二信任状之前，还包括: 若所述登录请求中指示没有有效的所述第一信任状时，指示所述应用客户端从所述CGC获取所述第一信任状，其中，所述CGC与所述应用客户端安装在同一个或不同的终端上。
3.如权利要求1或2所述的方法，其特征在于，所述查找对应所述第一用户名的第二信任状，包括: 在本地查找存储的对应所述第一用户名的第二信任状；或 从所述BSF获取对应所述第一用户名的第二信任状。
4.如权利要求3所述的方法，其特征在于，所述从所述BSF获取对应所述第一用户名的第二信任状，包括: 向所述BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，以使所述BSF查找对应所述第二用户名的密钥和密钥标示符，根据所述密语、密钥标示符、应用服务器的标识符采用设定算法生成所述第二信任状，其中，所述第二用户名与所述第一用户名关联，其中，所述密钥和密钥标示符为与所述CGC共享的密钥Ks和密钥标示符B-TID ； 获取所述BSF生成的所述第二信任状。
5.如权利要求4所述的方法，其特征在于，所述第二用户名为国际移动识别号IMS1、移动用户国际综合业务数字网号码MSISDN或携带所述MSI或MSISDN的标识。
6.—种生成信任状的方法,其特征在于,包括: 接收应用客户端请求登录的应用服务器的标识符； 采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证； 其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
7.如权利要求6所述的方法，其特征在于，所述采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，包括: 采用下面的算法生成所述第一信任状:
Credential=base64encoded{Trunc48[SHA-256(Ks_NAF||B-TID)]}。 其中，Credential为所述第一信任状，Ks_NAF为根据通用自引导架构GBA流程由所述Ks和所述应用服务器的标识符NAF_ID生成的，Trunc48为截取256位SHA-256值的低48比特，base64encoded为进行BASE64编码。
8.如权利要求6或7所述的方法，其特征在于，所述接收应用客户端请求登录的应用服务器的标识符，包括: 接收用户输入的所述应用服务器的标识符；以及 所述采用设定算法，将所述应用服务器的标识符、与BSF共享的密钥和密钥标示符生成第一信任状之后，还包括: 输出所述第一信任状给所述用户。
9.如权利要求6或7所述的方法，其特征在于，所述接收应用客户端请求登录的应用服务器的标识符，包括: 接收所述应用客户端的信任状获取请求，所述信任状获取请求包括所述应用服务器的标识符；以及 所述采用设定算法，将所述应用服务器的标识符、与BSF共享的密钥和密钥标示符生成第一信任状之后，还包括: 将所述第一信任状发送给所述应用客户端。
10.一种应用服务器，其特征在于，包括: 第一查找单元，用于当接收到应用客户端的根据第一用户名和第一信任状生成的登录请求时，查找对应所述第一用户名的第二信任状； 确认单元，用于根据所述第二信任状，确认所述应用客户端是否通过验证； 其中，所述第二信任状是由自引导功能装置BSF采用和信任状生成客户端CGC生成第一信任状的相同的方式生成的。
11.如权利要求10所述的应用服务器，其特征在于，还包括: 指示单元，用于若所述登录请求中指示没有有效的所述第一信任状时，指示所述应用客户端从所述CGC获取所述第一信任状，其中，所述CGC与所述应用客户端安装在同一个或不同的终端上。
12.如权利要求10或11所述的应用服务器，其特征在于，所述第一查找单元包括: 第二查找单元，用于在本地查找存储的对应所述第一用户名的第二信任状；或 第一获取单元，用于从所述BSF获取对应所述第一用户名的第二信任状。
13.如权利要求12所述的应用服务器，其特征在于，所述第一获取单元包括: 第一发送单元，用于向所述BSF发送所述第二信任状的获取请求，所述获取请求携带第二用户名，以使所述BSF查找对应所述第二用户名的密钥和密钥标示符，根据所述密语、密钥标示符、应用服务器的标识符采用设定算法生成所述第二信任状，其中，所述第二用户名与所述第一用户名关联，其中，所述密钥和密钥标示符为与所述CGC共享的密钥Ks和密钥标示符B-TID ； 第二获取单元，用于获取所述BSF生成的所述第二信任状。
14.如权利要求13所述的应用服务器，其特征在于，所述第二用户名为国际移动识别号MS1、移动用户国际综合业务数字网号码MSISDN或携带所述MSI或MSISDN的标识。
15.一种信任状生成客户端CGC，其特征在于，包括: 第一接收单元，用于接收应用客户端请求登录的应用服务器的标识符； 第一生成单元，用于采用设定算法，将所述应用服务器的标识符、与自引导功能装置BSF共享的密钥Ks和密钥标示符B-TID生成第一信任状，以使所述应用服务器根据从BSF获取的对应所述第一用户名的第二信任状对应用客户端进行登录验证；其中，所述第二信任状是由所述BSF采用与生成所述第一信任状的相同的方式生成的。
16.如权利要求15所述的CGC，其特征在于，所述第一生成单元包括: 第二生成单元，用于采用下面的算法生成所述第一信任状:
Credential=base64encoded{Trunc48[SHA-256(Ks_NAF||B-TID)]}。 其中，Credential为所述第一信任状，Ks_NAF为根据通用自引导架构GBA流程由所述Ks和所述应用服务器的标识符NAF_ID生成的，Trunc48为截取256位SHA-256值的低48比特，base64encoded为进行BASE64编码。
17.如权利要求15或16所述的CGC，其特征在于，所述第一接收单元包括: 第二接收单元，用于接收用户输入的所述应用服务器的标识符；以及 所述CGC还包括: 输出单元，用于输出所述第一信任状给所述用户。
18.如权利要求15或16所述的CGC，其特征在于，所述第一接收单元包括: 第三接收单元，用于接收所述应用客户端的信任状获取请求，所述信任状获取请求包括所述应用服务器的标识符；以及所述CGC还包括: 第二发送单元，用于将所述第一信任状发送给所述应用客户端。
【文档编号】H04L29/06GK104348801SQ201310329541
【公开日】2015年2月11日 申请日期:2013年7月31日 优先权日:2013年7月31日
【发明者】陈璟 申请人:华为技术有限公司