FIDO UAF协议

本文对UAF协议进行了详细介绍，说明了注册、认证、交易确认和注册操作中各实体的具体处理过程和消息格式。最后对于本协议对安全、性能等方面的考虑进行了说明。FIDO CLIENTFIDO SERVERInittion to reDeregister this authenticator3公共数据类型31版本interface Versionreadonly attribute unsigned short major;readonly attribute unsigned short minor;32操作类型enum OperationiAuthDere33操作头dictionary Operation Readerrequired version upv;//UAF协议版本。 major=1, minor=1required Operation op; //"Reg" "Auth""Dereg第三方业务去进行断言的应用标识符,可按照如卜方法设置app|D。如果在请求中该项没有或者为空, FIDO UAF客户端的appD就是调用者的 Facet如果消息中的appD与调用者的 FacetID相同,F1 DO UAF客户端必须接受该消息如果是一个UR, FIDO UAF客户端必须从该URI加载可信的 FacetiD标识符列表并且,如果调用者的 FacetEd与可信的 FacetEd列表中的的一个匹配,客户端就必须接受该请求。认证器新产生的密钥对将与该应用标识符关联该标识符被UAF客户端对调用 UAuth. Key进行操作的应用的资格进行认定DOMString appID;业务系统创建的个会话标识符。业务系统可以在其中存储注册会话过期时间,协议版本和这其他一些数据。这些数据对于F| DO UAF客户端来说是透明的。F|DO服务可以拒绝会话不匹配的应答,比如没有会话,或者会话中的数据被篡改DOMString serverData;Extension]exts;//UAF消息扩展项列表34认证器证实D( AAID: Authenticator Attestation id)typedef doCString AAId每个认证器都必须有一个AAID用于从全局上识别启用了∪AF的认证器模型。AAD必须在所有的启用了UAF的认证器模型中,唯一表示某个具体的认证器模型。AAID的格式为M”,其中#”是分隔符V”是认证器厂商代码,为4个16进制数。FIDO联盟负责分配●“M”是认证器模型码,为4个16进制数。认证器厂商负责分配。不同的安全特征的认证器,其AAD不同。增加新的固件/软件,或者改变了底层的硬件保护机制都会引起安全特征的变化,从而需要一个新的AAID每个AAID都是不同的,并都与一个不同的认证元文件相关3. 5KEYIDtypedef docstring key|D;//base64-url编码keyD用于在一个AAD范圉内唯一的标识一个 UAuth. key,由认证器产生并且在FDO服务中注册。业务系统使用(AAD,KeyD)这个二元组唯一标识一个认让器的注册。如果F|Do服务给一个特定认证器提供具体的信息,必须使用这个二元组。KeyD必须是base64-url编码的在认证和注销操作中,FDO服务需要提供KeyD给认证器,认证器用于定位只体的密钥并执行相应的操作。漫游认证器不具备内部存储,并且也不能依赖ASM去保存密钥,在注册操作中以Authenticator RegistrationAssertion. assertion.KeyD来提供密钥句柄。在认证过程中,从FDo服务获取密钥句柄。3. 6Server Challengetypedef DOMString Server ChallengeServer Challenge是个服务端提供的随机数。服务端用它来验证个应答是新的,还是已经被处理过。该随机数要有足够高的随机性3. fInal ChallengeParamsdictionary FinalChallenge Paramsrequired doMString appId://从 Operationheader中的 appID字段获取required Server Challenge challenge;/人请求消息中的cha‖ lenge字段获取required doMString faceteD;// FIDO UAF客户端确定,并且依赖于调用程序DO UAF客户端发送给FDO服务的TS信息,用于把本操作绑定到TS通道上required ChannelBinding channel Binding3.8TLS Channel BindingChannel Binding包括了绑定的TLS信道信息。FDo服务可能会验证绑定的信道,以防止中间人攻击,此时需要支持如下的信道绑定方法● TLS channel|D● serverEd pointtls Server CertificatetlsUpdate如果 FIDO UAF客户端能获取与绑定方法相关的数据,必须按照相关规范去使用这些数据;FiDO服务必须支持所有的信道绑定方法,如果信道绑定验证不通过,HDO服务会拒绝操作如果信道绑定数据对于浏览器或APP来说是可用的,这些数据需要传递给 FIDO UAF客户端;如果信道绑定数据对于wEB服务来说是可用的,这些数据需要传递给FDO服务。Channel Binding具体定义如下:dictionary ChannelBindinglDOMString server End Point;/「S服务器诎书的摘要(以base64-ur编码)。DOMString tls ServerCertificate;//LS服务器证书∥/如果TLS信道的 Finished结构体对UAF客户端不可用,则必须提供DOMString tlsUpdate;/LS信道的 Finished结构体/如果客户端TLS协议栈不给应用提供TLS信道,则必须提供DOMString cid pukey;//UTF-8编码的 WkeY的base64-url编码3.9JwkKeyJwkKeγ是一个针对椭圆曲线的web公钥的JsoN封装。该公钥被客户端TLS协议栈所产生,并用于对业务系统建立安全信道。 channelID规定使用某种特定的椭圆曲线和特定的坐标类型。dictionary JwkKeyrequired doMString kty="EC";// ChannelId使用的密钥类型required docString crv="P-256";/公钥作用的椭圆曲线,当前为secp256-1required doCString x;//公钥的x坐标required doCString y;/1公钥y坐标3. 10EXtensionFDO扩展项可以出现在UAF协议中、认让命令中,或者认让器签发的断言中。每个扩展想都有一个标识符,并且其名字空间为全局。对于扩展项的处理可以定义两种不同的策略,第·种就是如果碰到不能识别的扩展项,则终端处理,第二种就是忽唅不能识别的扩展项。通用扩展项可应用在不同的操作中。dictionary Extensionrequired docString id;/)扩展项的标识符required doCString data;/)展项数据required boolean fail if unknown;//.假,则可以忽略不能识别的扩展项FDO客户端可以处理扩展项,或者把展项传递给ASM,未知的展项必须透传。FDO认证器可以处理或者忽略扩展项。如果FDO认证器不能识别扩展项并且fail if unknown被设置,就必须产生一个错误。在实体间传递扩展项时, fail if_ un known不能改变。FIDO UAF协议的消息没有签名,如果想依赖扩展项灾现安全,那么这些扩展项必须与认证器断言中( TAG UAFV1 REG ASSERTION或 TAG UAFV1 AUTH ASSERTION)的一个相关扩展项关联。如果安全已经做了升级,那么就没有必要把扩展项标识为 fail if unknown);如果安全做了降级,扩展项必须被标识为 fail if unknown。3.11 Match Critera用来表示服务器策略中使用的匹配规则。如果所有的字段都匹配,才认为该对象与一个认证器匹配ry Match Criteria待匹配的AAD列表,该字段可以与 keyIDs、 attachmenthint、 authentication version∥/及exts结合,不能与其他的字段结合。如果 AuthenticationInfo.ad与列表中的//个项匹配,则认为匹配成功AAID[ aaid待匹配的认证器模型的供应商列表,AAD的前4个字符就代表的供应商DOMStringll vendorID待匹配的认证器KeyD列表Key|D]keDs标志/用户认证标志。满足如下条件时认为匹配成功:f((AuthenticatorInfo user Verification = Match Criteria)l I((AuthenticatorInfo userVerification &USER VERIFY ALL)==0)&&((Match Criteria. user Verification USER VERIFY ALL)==0)&&((Authenticatorlnfo userVerification Match Criteria. userVerification )!=0该宁段可以从 Metadata Statement user Verification Details派生unsigned long user Verification空钥保护标志,与 AuthenticatorInfo. key Protection一个标志位匹配即可unsigned short key Protection/兀配器保护标志,与 Authenticatorlnfo. matcher Protection中一个标志位匹配即可unsigned short matcher Protection/附带提示标志,与 Authenticatorlnfo, attachmenthint中一个标志位匹配目可unsigned long attatchmenthint;∥交易显示标志,与 AuthenticatorInfo tc Display中个标志位匹配即可unsigned short tcDisplay认证算法列表。只要有一项与 AuthenticatorInfo. authentication! orithm匹配即可unsigned shortl aut∥/断言方案列表。只要有一项与 Authenticatorlnfo, assertion scheme匹配即可DOMStringl assertion Schemes证实类型列表。与 AuthenticatorInfo attestation Types中一项匹配即可unsigend short[ attestation Types认证器版木。该值小于等」 TAG UAF1 REG ASSERTION或者// AG UAF1 AUTH ASSERT|ON中的 Authenticator Version即可,或者不超过其他不同的断言方案中对应的值。unsigned short authentication version;∥匹配策略的扩展项Extension[ exts3.12Policdictionary policy∥/认证器特征二维列表,服务器用于接受注册、认证操作。看做一个集合的列表。集合之间是|的关系。集合中的元素是&&关系,用于检查与认证器的匹配。required Match Criterial[ acceptedMatch criteria[] disallowed;/黑名单,从 accepted中剔除FIDO服务器可以接受任意的认证器,此时策略如下acceptedRuserVerification": 102314服务器策略处理规则FIDO UAF客户端在解析服务器策略的过程中必须遵循一定的规则。4.1注册Policy. accepted是一个集合列表,每个集合中都包括了服务器希望用户注册的认证器的规则遵循列表的优先级,第一个元素优先级最高,依次递减从列表中选择匹配度最高的集合●收集可用认证器信息忽略与 Policy. disallowed匹配的认证器把收集信息与策略所强加的匹配规则相匹配●引导用户注册在最终选择集合中的认证器42认证和交易从列表中选择与当前可用的认证器匹配度最高的集合收集可用认证器信息忽略与 Policy. disa‖lwed匹配的认证器●把收集信息与策略所描述的匹配规则相匹配引导用户用选择的集合中的认证器去进行认证●只有当一个集合中所有的元素与认证器匹配才接受操作43例子下面的策胳匹配指纹或者人脸识别认证器。accepted["userVerification": 2," authenticationAlgorithms":[1, 2, 5, 6], assertionSchemesUAFV1TLV["userVerification :16, authenticationAlgorithms":[1,2, 5,6, Schemes" UAFVITLV卜面的策咯匹配同吋实现了指纹和人睑识别的认证器,但二者是叫替换的。accepted["user Verification": 18, authenticationAlgorithms":[1, 2, 5,6], assertionSchemes[UAFVITLV卜面的策咯匹配同吋实现了指纹和人脸识别的认证器。accepted":[R userVerification": 1042,authenticationAlgorithms":[1, 2, 5,61assertion Schemes:[UAFV1TLV]HI下面的策咯匹配两个认证器,个基于指纹,个基于人脸识别。acceptedtuserVerification 2, "authentication Algorithms":[1, 2, 5,6, assertion Schemes「"UAFV1TLV"}[ Verification ": 16, authentication Algorithms":[1, 2, 5, 6],assertion SchemesAFVITLV I下面的策略兀配两个认证器,一个基于绑定指纹,一个基于绑定人脸识别。accepted(userVerification 2, attachmentHint ":1,authenticationAlgorithms":[1, 2, 5,61,assertion Schemes":["UAFVITLV 1t Verification": 16, attachmentHint": 1, authenticationAlgorithms":[1, 2, 5,6]assertion Schemes":["UAFV1TLV"JH下面策略匹配|D为1234的供应商认证器。accepted[IC:1234,authenticationAlgorithms":1,2, 5, 6], assertion Schemes":"UAFV1TL」5版本协商UAF协议中包括多个版本:UAF协议版本、ASM版本、密钥注册数据( Key registration Data)和密钥签名数据( Key signed Data)版本。FIDo服务器必须要解析密钥注册数据和密钥签名数据,前提是FDO服务器理解数据编码及其内容。UAF的不同版本支持一系列的断言方案(密钥注册数据和密钥签名薮据)版本。同样,ASM的不同版本支持一系列的断言方案。FIDO UAF客户端必须要选择能产生适当的版本数据。版本协商过程如下:1)创建一个包活ASM版木和UAF协议版木的版木对集合 FC Version set2)把UAF客户端所支持的所有版本对增加到集合中,比如[{upv1, asm version1,{upv2,aspersion2},其中ASM版本从 Authenticatoflnfo. asmversion获取,UAF协议版本从AuthenticatorInfo, assertion Scheme派生出来3)求UAF消息中的upv集合与 FC Version set的交集4)选择UAF消息策胳所允许的认证器,对每个认证器:a)构造一个包括了认证器支持的 asm version和兼容upv的版本对的集合Author version set,比如[{upv1, aspersion1},{upv2, aspersion2}……b)求 Author Version set与 FC Version set的交集,并从中选择最高的版本对。首先选择up最高的,然后再选择 asm version最高的c)使用剩余的版本对。在UAF中,每个版本都包括主版本和次版本,需要首先比较主版本,再比较次版本。在每个UAF消息中都有upv,UAF协议版本协商总是发生在UAF客户端和uAF服务之间6注册操作汴册操作让FDo服务和认证器就一个认证密钥达成一致,具体流稈如下图所示:serAuthenticatoAsMFUser AgentRP Web App FIDO Server,键& Web ServerP0+回tmM引hitnE Simal artaban ofUAF算+TPFR日9日+5的t1. llan fic由p|器kEla Secr When coons,e4ioa tripetat却 fE an sara mel and2E3 tic ocdd w etpry2阻2c日闯解量gn beha tofuser其中11a、11b、12和13不一定必须出现,因为相关的数据可能被缓存。其中的加密数据流入如下图所示:strationNote Ths represens a FDO UAF I=4F EmbeddedRe lyingSM+ FIDO ClientParstf eAuthnrBrowser(mycorp. com)select Authenticator accoding to Doteyusername, poleCheak Apoil get tisDale (e channel d ecJgenerate APiKey random compute access keyApplD, challengeak:m has App D APIRey Personal, CalerIDusername u, ak: ha sh(fcpkeyfhandle haaid, k. fc, h, attestation cert, reg- cntr, cntr,signature(aaid, fe reg- cntr, cntr kaaid, k fc, h, attestation cert,reg.cntr, cnt, skey kHandle h1)F|DO服务发送AppD、 policy、 challenge和 username给F| DO UAF客户端2) FIDO UAF客户端从 challenge和一些其他值计算出最终的挑战 finalchallenge,发送App|D、finalcha|lnge和 username给认证器3)认证器创建一个密钥注册对象TAG_UAF1KRD,其中包括了 finalchallenge的摘要FCH、新创建的用户公钥 Auth:ub、一些其他的值并进行签名4)FDO服务对密钥注册对象进行验证6.1注册请求消息下面是个注册请求消息的具体数据[upVmajorminor, 1op": Regappld""https://uaf-test-1.noknoktest.com8443/sampleapp/uaf/facetsserverData": ljycjPZYIWMaQltKLrjROIXQHmYGotssYGjP5mgjsDaM17RQgqodI3NNDDTX9d-asR 6h GgcIrU2 F2Yj-12S67v5VmQHj4eWVseLulHdpk2v hHtkSvv dfqL4n2liUY6XZWVbOnvgchallenge": "H9iW9 yA9aAXF_lelQoi Dhuk514Ad8TqvOzCnCqkDpousername : apapollcyaccepted":[userVerification :512key Protection":1