GB/T40018-2021
信息安全技术基于多信道的证书申请和应用协议
Informationsecuritytechnology—Certificaterequestandapplicationprotocolbasedonmultiplechannels
- 中国标准分类号（CCS）L80
- 国际标准分类号（ICS）35.040
- 实施日期2021-11-01
- 文件格式PDF
- 文本页数22页
- 文件大小1.41M
以图片形式预览信息安全技术基于多信道的证书申请和应用协议
信息安全技术基于多信道的证书申请和应用协议
国家标准 GB/T40018一2021 信息安全技术基于多信道的 证书申请和应用协议 nformationseeurityteechnology一Certifieaterequesamdapplieation" protoeolbasedonmultiplechannels 2021-04-30发布 2021-11-01实施 国家市场监督管理总局 发布 国家标涯花管理委员会国家标准
GB/T40018一2021 目 次 前言 引言 范围 规范性引用文件 术语、定义和缩略语 3.1术语和定义 3.2缩略语 总则 基于多信道的证书申请协议 基于多信道的数字签名与验签协议 6.1数字签名 6.2签名验证 基于多信道的文件加解密协议 7.1文件加密密钥传输协议 7.2文件解密密钥传输协议 12 附录A(资料性附录兼容性分析 14 附录B资料性附录)采用二维码的证书申请协议 15 附录c资料性附录应用场景 16 参考文献 18
GB/40018一2021 前 言 本标准按照GB/T1.1一2009给出的规则起草
请注意本文件的某些内容可能涉及专利
本文件的发布机构不承担识别这些专利的责任
本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口
本标准起草单位:科学院数据与通信保护研究教育中心、科学院大学,浙江蚂蚁小微金融 服务集团股份有限公司、北京信安世纪科技股份有限公司,联想(北京)有限公司、国民认证科技(北京 有限公司、数安时代科技股份有限公司、上海市数字证书认证中心有限公司、北京数字认证股份有限 公司
本标准主要起草人:牛莹姣、荆继武、高能、陈星、刘丽敏、汪宗斌、贾世杰、雷灵光、杨楠、郑肪昱、 马原、王平建、吕娜、钱文飞、张永强、王天华、林雪焰
GB/T40018一2021 引 言 本标准从信息安全角度提出了基于多信道的证书申请和应用协议,多信道包括近场信道和网络信 道
近场信道指智能移动设备和证书认证系统终端或业务系统终端近距离连接的信道,如人工信道,光 学信道、NFC等
网络信道指证书认证系统或业务系统通过网络连接智能移动设备的信道
近场信道 的特征是带宽小,不能进行大量数据传输,数据以明文形式传递,但是通过该信道发送和接收的数据较 不易被窃听,且能通过面对面的方式进行通信双方身份的鉴别
本标准通过引人近场信道协同网络信 道完成证书申请和应用能更加有效地抵御信道窃听、数据篡改、终端假冒等攻击
GB/T40018一2021 信息安全技术基于多信道的 证书申请和应用协议 范围 本标准规定了利用智能移动设备进行证书申请和应用协议,包括证书申请协议、数字签名与验签协 议、文件加解密协议
本标准适用于多信道环境中应用系统的设计、开发、测试
规范性引用文件 下列文件对于本文件的应用是必不可少的
凡是注日期的引用文件,仅注日期的版本适用于本文 件
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件
GB/T250692010信息安全技术术语 GB/T37092一2018信息安全技术密码模块安全要求 GM/T0014一2012数字证书认证系统密码协议规范 术语、定义和缩略语 3.1术语和定义 GB/T250692010界定的以及下列术语和定义适用于本文件
3.1.1 近场信道nearfieldchanel 智能移动设备和证书认证系统终端或业务系统终端近距离连接的信道
示例，人工信道,光学信道,NFC等
3.1.2 网络信道networkchamnel 证书认证系统或业务系统通过网络连接智能移动设备的信道
3.1.3 厂商IDvendorID 应用服务器分配给智能移动设备开发厂商、表明智能移动设备开发厂商身份的唯一标识
3.1.4 厂商私钥vendorprivatekey 智能移动设备开发厂商在智能移动设备中预先植人的用于证明厂商是否可信的密钥对中的私钥
3.1.5 厂商公钥vendorpubliekey 智能移动设备开发厂商在智能移动设备中预先植人的用于证明厂商是否可信的密钥对中的公钥
3.2缩略语 下列缩略语适用于本文件
GB/T40018一202 Rules DER;可辨别编码规则(DistmgushedEacoding" D标识(Identificeation) NFC;近场通信(NearFieldCommunication andomNumber) RN随机数(Rat esourceIdentifier URI统一资源标识符(UniversalRee 总则 安装有密码模块(软件或硬件)的智能移动设备,可以代理申请人向证书认证系统申请证书,与业务 系统协作使用证书实现签名、验签,文件加/解密等功能
本标准描述的智能移动设备应具有独立联网 能力且具备二维码扫描,NFC或蓝牙等功能
安装的密码模块应符合GBy/T37092-2018的要求,且 通过主管部门的核准,提供密钥管理和密码运算功能
基于多信道的证书申请和应用协议框架见图1
证书应用 业务系统 智能移动设备 数字签名 提供身份鉴别服务，如统一身份认证 系统 身份鉴别签名 -内容签名 提供待签名内容，如支付平台 签名验证 证书申请 证书认证 身份被签别 身份鉴别签名验证 系统 密码模块 内容签名验证 对内容进行签名，如学位证书 文件加/解密 进行文件加密，如邮件系统 文件加密钥传辅 进行文件解密，如邮件系统 文件解密密钥传输 图1基于多信道的证书申请和应用协议框架图 协议中定义二维码格式为:TAG://CONTENT,其中TAG表示协议的类型,CONTENT表示二 维码中要携带的信息,CONTENT中内容采用DER编码,并使用BASE64编码转变成可打印字符串
其余通信内容均采用DER进行编码
关于协议中定义的二维码格式与通用二维码格式的兼容性分析 参见附录A
协议中使用了AsN.1定义的数据类型,如表1所示 表1数据类型描述 数据类型 描述 PrintableString 可打印字符串 OCTETSTRING 字节串 INTEGER 整数 BITSTRING 比特串由0和1组成 B0(oLEAN 布尔型,取值为“TRUE”或"FAL.SE" SEQUENCE 个或多个字段组成的有序序列
GB/40018一2021 基于多信道的证书申请协议 本协议规定了智能移动设备利用近场信道协同网络信道向证书认证系统申请证书的过程,协议开 始之前申请人应在可信证书认证系统的用户注册管理系统完成身份审核,并提醒申请人使用智能移动 设备获取证书认证系统通信地址后开始协议第一步,申请人对证书认证系统的鉴别不在本标准范围内 协议流程见图2 近场信道:获取UR1、RN,SessionlD c网络信道 发这运油油武消区 d用户通过系统终端输入 智能移 b生成VerifieationCode Vt并对请 证书 网络信道证书申请响应消息 动投备 证系绕 绝售道下整书或 注:图中虚线表示可选或依赖于上下文关系的消息
图2证书申请协议流程图 基于多信道的证书申请协议流程如下 智能移动设备通过近场信道获取证书认证系统生成的证书申请登记报文,其数据结构如下 a ApplyCertificateRegistration::=SEQUENCE tag PrintableString， uri UTF8String(Size(1.MAX))， OcTETsTRING rn sessionlD OCTETSTRING 证书申请登记报文各个域的含义如下 -tag域值为CERT,表示协议类型为证书申请; uri域是证书认证系统的网络信道通信地址; 域为随机数; rn session nID域为本次证书申请过程的会话ID. 智能移动设备生成随机验证码VerificationCode,应至少8个字节
b 智能移动设备通过网络信道向登记报文中的URI发送证书申请请求消息,其数据结构如下 ApplyCertifceateRequest::=sEQUENCE V version ersion OcTETSTRING. rn OCTETSTRING sessionlD devicelID UTF8String(Size(1.MAX))， deviceName UTF8String(Size(1.MAX))， pubKey SubjectPublicKeylnfo. signatureOfNegotiatingData Signature vendorID UTF8String(Size(1.MAX))OPTIONAI vendorSignature SignatureOPTIONAI 证书申请请求消息中各个域的含义如下
GB/T40018一202 域为请求消息的版本,其结构如下 -ersion version:;=INTEGERvl(0) 域为智能移动设备获得的RN; rn sessionID域为本次证书申请过程的会话ID devieelID域为智能移动设备ID; -devieeName域为智能移动设备名称 pubKey域为智能移动设备上密码模块中申请人的签名公钥和相应的公钥算法,其数据 结构如下 SEQUENCE SubjeetPublickKeylnfo:;一 algorithm Algorithmldentifier, subjeelPubieKey BITSTRING 其中,公钥算法使用算法标识符Algorithmldentifler结构来表示
SIgn natureONegotiatingData域为智能移动设备上密码模块中申请人签名私钥对Negoti atingData的签名及使用的签名算法,其中tag值为CERT,其数据结构如下: Signature::=SEQUENCE signatureAlgorithm Algorithmldentifier， BTsSTRING signature 其中,signature域为申请人签名私钥对NegotiatingData的DER编码签名的结果
NegotiatingData数据结构如下 sEQUENCE NegotiatingData::= tag PrintableString， UTF8String(Size(1.MAx)). uri 0cTETsTRING rn OCTETSTRING. sessionlD verificationCode UTF8String(Size(1..MAx)). UTF8String(Size(1.MIAX)) devicelD vendorID域为厂商ID,可选; vendorSignature域为厂商私钥对RN的签名,可选
证书认证系统接收到智能移动设备的请求消息后,要求申请人通过证书认证系统终端输人b) d 中所生成的VerificationCode
然后对智能移动设备的证书申请请求消息进行验证,包括 验证RN,SessionlD是否有效,使用申请人签名公钥验证签名是否正确 商ID是否在可信厂商列表中(可选): 商私钥对N的签名是否有效(可选) e 证书认证系统通过网络信道向智能移动设备回复证书申请响应消息,其数据结构如下 ApplyCertifieateResponse;;=SEQUENCE status B0oOLEAN. 6 OPTIONAL ApplyCertifieateR response ResponseIype6 证书申请响应消息中各个域的含义如下 s域为证书申请处理结果,true表示申请成功,false表示申请失败; status
GB/T40018一2021 -response域为证书下载地址或证书,其数据结构如下 ApplyCertifieateResponseType::=CHOICE [0]UTF8String(Size(1...MAX)， ur fullCert [1]SEQUENCES1ZE(1...MAXOFCertifieate fD 按照GM/T0014一2012的要求下载证书,也可通过近场信道获取证书下载消息,其数据结构 如下 CertificateDownloadInfo:;=SEQUENCE PrintaleStrin ing tag UTF8string( (Size(1.MAX) ur 证书下载消息中各个域的含义如下 -ug域为CERTDowN -uri域为证书下载服务的地址
基于二维码的证书申请协议示例参见附录B 基于多信道的数字签名与验签协议 6.1数字签名 6.1.1用于身份鉴别的数字签名协议 本协议规定了利用智能移动设备的密码模块进行签名完成身份鉴别的过程,用户对业务系统的鉴 别不在本标准范围内,协议流程见图3
a近场信道:获取URI、RN.SessionlD、 Eaesion等消息 SystemDescription、 智能 业务
验证 移动 bUR指定信道 系统 设备 发送身份签别请求消息 图3用于身份鉴别的数字签名协议流程图 用于身份鉴别的数字签名协议流程如下 智能移动设备通过近场信道获取身份鉴别初始化报文,包括提供身份鉴别服务业务系统的 a URI,RN、SessionlD业务系统描述和扩展字段等,其数据结构如下: Authenticeationnitialization;;=SEQUENCE PrintableString tag UTF8String(Size(1..MAX)). uri OCTETsTRING rn OcTEsTRING sessionID systemDescription PrintableString， Printablestring" OPTIONA eXtenSIOnm 身份鉴别初始化报文中各个域的含义如下 ag域值为AUTH,表示协议类型为身份鉴别
GB/T40018一202 uri域为提供身份鉴别服务业务系统的通信地址; n域为随机数 sessionlD域为本次身份鉴别过程的会话ID; systemDeseription域为提供身份鉴别服务业务系统的描述; extension域为扩展字段可选)
智能移动设备显示a)中获取到的URI及系统描述信息,用户在智能移动设备端确认后,通过 b URI指定信道向业务系统发送身份鉴别请求消息,其数据结构如下 AuthenticationRequest:;=SEQUENCE Version. version OcTETSTRING rn sessionID OcTESTRING. PublieKeyForm pubKey signatureOfTUc Signature 身份鉴别请求消息中各个域的含义如下 version域表示请求消息的版本 域表示智能移动设备获得的随机数RN; rn session nnlD域表示智能移动设备获得的会话ID; pubkey域表示智能移动设备用户的公钥信息或证书信息
如果发送内容为公钥信息 则协议开始之前用户已在业务系统注册公钥等信息,其数据结构如下 PubliekeyForm;=CHoCcE [o]subjeetPubliekeylnfo pubKeyInfo ]CertifieateType certificate CertifieateType:;=CHOICE [0]UTF8String(Size(1..MAXN)). ur fulCert [1]SEQUENCES1ZE(1..MAXOFCertifieate signatureOfTrUC域表示智能移动设备用户签名私钥对TUC的DER编码的签名,其中 tag的值为AUTH,TUC数据结构如下 SEQUENCE TUC::= PrintableString， tag UTF8strng( Size(1..MAX))， ur1 Content content Conent=sEoUENcE OCTETSTRING. rn OcTETsTRING sessionlD 业务系统接收到智能移动设备的身份鉴别请求消息后,验证SessiomD是否有效
如果有效 对请求消息进行验证,验证RN、公钥以及对TUC的签名是否有效
该协议的典型应用场景参见附录C中的C.2
GB/40018一2021 6.1.2信息内容数字签名协议 本协议规定了利用智能移动设备的密码模块完成信息内容数字签名的过程,协议流程见图4
a近场信道，获取UR!、AcesCo等消息 bUR指定信道
发送请求消息，获取待签名内容 智能 业务 cUR指定信道，待签名内容 移动 系统 设备 dUR指定信道:发送内容签名结果消息 图4信息内容数字签名协议流程图 信息内容数字签名协议流程如下 智能移动设备通过近场信道获取内容签名请求消息,包括业务系统的访问地址URI及访问令 a 牌信息AccessCode,其数据结构如下 ， contentSsignatureRequest:;=SEQUENCE PrintableString tag UTF8String(Size(1..MAX)) uri accessCode OCTETSTRING 内容签名请求消息中各个域的含义如下 -tag域值为sIGN,表示协议类型为内容签名; uri域为签名内容提供方提供的用户获取待签名数据以及上传签名信息的地址; ecesCode域为访问令牌信息
智能移动设备通过URI指定信道向该URI发送请求消息,获取待签名内容,其数据结构 b 如下 GetContentRequest;;=sEQUENCE Version. version OcTETSTRING accessCode 待签名内容获取消息中各个域的含义如下 域表示请求消息的版本 -version scoad域表示智能移动设备获得的访同令牌信息.Accesciade. access 业务系统通过URI指定信道向智能移动设备发送待签名内容,其数据结构如下 TobeSignedContent SEQUENCE ::一 INTEGER， statuS Printablestring resp0nse 上述响应消息中各个域的含义如下 -status域表示业务系统对请求消息的处理结果， -response域表示响应消息体;如果请求消息处理成功,则为待签名内容;如果失败,则为失 败原因
d)智能移动设备显示签名内容,提示用户确认是否进行数字签名,用户确认后通过URI指定信
GB/T40018一2021 道发送内容签名结果消息,其数据结构如下 SEQUENCE Colteusignature1一 BOOLEAN type re(OfTUC OPTIONAL sigature signature 内容签名结果消息中各个域的含义如下 -type域为用户是否对内容签名:true表示用户确认进行签名,false表示用户取消签名; signatureOfTUC域为智能移动设备上用户签名私钥对TUC的DER编码的签名,其中 tag的值为sIGN,TUC数据结构如下 TUC::=SEQUENCE Pintablesirng" tag ur UTF8String(Size(I.MAX)). Content cOntent Content::=SEQUENCE PrintableString respOnse 该协议的典型应用场景参见C.3
6.2签名验证 6.2.1用于身份鉴别的数字签名验证协议 本协议规定了利用智能移动设备的密码模块进行签名验证,完成对目标系统或实体进行身份鉴别 的过程,协议流程见图5
a近场信道; 获取URi、AesCe等消息 bURI指定信道，发送身份鉴别请求 消息 智能 业务 d验证，并显 移动 示结果 系纷 设备 eUR指定信道 回复身份亚啊应消息 图5用于身份鉴别的数字签名验证协议流程图 用于身份鉴别的数字签名验证协议流程如下 智能移动设备通过近场信道获取用于身份鉴别的签名验证初始化消息,包括被鉴别方的URl a 及其访问令牌信息AecessCode,其数据结构如下: SEQUENCE VerifyAuthenticationSignature::= PrintableStrimg tag UTF8String(Size(1..MAX)， uri accessCode OCTETSTRING 用于身份鉴别的签名验证初始化消息中各个域的含义如下 tag域值为AVERIFY,表示协议类型为用于身份鉴别的签名验证; uri域为被鉴别方的通信地址 essCode域为访问令牌信息
acce
GB/T40018一2021 b 智能移动设备生成RN,并通过URI指定的信道发送身份鉴别请求消息,其数据结构如下: VerifyRequest::=SEQUENCE？ Version version OCTETSTRING rn accessCode 0CTETSTRING， devicelID ze(1..MAX UTF8Str tnmg(sia 身份鉴别请求消息中各个域的含义如下 verSion 域为鉴别消息的版本; 域为智能移动设备生成的RN; -rn es essCode域为智能移动设备获得的访问令牌信息AeeessCode acce devieelID域为智能移动设备ID. 被鉴别方接收到身份鉴别请求消息,验证其中的访问令牌信息AcesCodle是否合法,并通过 URI指定信道向智能移动设备回复身份鉴别响应消息,其数据结构如下 VerifyResponse::=SEQUENCE INTEGER， statuS Responselnformation， reSpOnse CertifieateTypeOPTIoNAL certificate 身份鉴别响应消息中各个域的含义如下 status域表示对请求消息的处理结果; rresponse域表示响应消息体;如果对请求消息处理失败,则为失败原因;如果成功,则为业 务系统签名私钥对RD的DER编码的签名,其数据结构如下 Responselnformation;;=CHoCE [[o]BITSTRING. failReason ignatureOfRD [1]Signature RD SEQUENCE ::一 0cTETSTRING. rn UTF8String(Size(1...MAX)) deviceID -certifieate域为证书下载地址或业务系统证书,其数据结构如下 CertificateType:;=CHoCE [o]UTF8String(Size(1.MAX)). uri ulCert [1]SEQUENCESIZE(1...MAXOFCertificate d 智能移动设备接收到身份鉴别响应消息,提取证书或者通过URI下载证书,解析证书中的主 体和公钥信息,用公钥验证业务系统对RN和deviceID的签名是否有效,并将验证结果显示 给用户
6.2.2信息内容数字签名验证协议 本协议规定了利用智能移动设备的密码模块完成信息内容数字签名验证的过程,协议流程见图6
GB/T40018一2021 近场信道 获取URI、AccessCode等消息 bUR指定信道 智能 发送内容求消B 业务 d验证并显示 移动 系统 结果 设" eUR指定信道回复内容签名验证响应消息 图6信息内容数字签名验证协议流程图 信息内容数字签名验证协议流程如下: 智能移动设备通过近场信道获取内容签名验证初始化消息,包括业务系统访问地址URI以及 a 访问令牌信息AccessCode,其数据结构如下: VerifyCont ueansgnat ture:;=SEQUENCE uableString Print tag UTF8String(Size(1.MAX))， uri accessCode OCTETSTRING 内容签名验证请求消息中各个域的含义如下 tag域值为CVERIFY,表示协议类型为内容签名验证; -un域为业务系统的通信地址， accessCode域为访问令牌信息
智能移动设备通过URI指定信道发送内容签名验证请求消息,其数据结构如下 b VerifyContentSignatureRequest::=SEQUENCE version Version OcTErsTRING accessCode 内容签名验证请求消息中各个域的含义如下 version域为内容签名验证请求的版本; accessCode域为智能移动设备获得的访问令牌信息AccessCode URI所在业务系统接收到内容签名验证请求消息后,验证其中的访问令牌信息accessCode是 否合法,并通过UR1指定信道向智能移动设备回复内容签名验证响应消息,其数据结构如下: VerifyContentSigatureResponse:;=SEQUENCE《 UTF8String" message signatureOfMessage Signature certificate CertifcateType 内容签名验证响应消息中各个域的含义如下: message域表示被签名的数据; OfMessage域表示签名信息 signature cerificetc域为证书下载地址或业务系统证书,其数据结构如下 certifieateType::一 =CHOICE [0]UTF8String(Size(1...MAX)). uri fulCert [1]SEQUENCEs1ZE(1.MAX)OFCertifieate 10
GB/40018一2021 d 智能移动设备接收到内容签名验证响应消息后,从消息中提取证书或者通过URI下载证书， 解析证书中的主体和公钥信息,验证签名信息是否为证书主体对message的签名,并将验证 结果展示给用户 该协议的典型应用场景参见C.4
基于多信道的文件加解密协议 7.1文件加密密钥传输协议 本协议规定了利用智能移动设备的密码模块为文件系统提供密钥进行文件加密的过程,协议流程 见图7
a近场信道，获取简单文件加密的密钥初始化 消意 bUR指定信道
使用加密密钥加 文件系统 智能移动设备 发送简单文件加密的密钥传输响应消息,包括el和 密文件 c2 图7文件加密密钥传输协议流程图 文件加密密钥传输协议流程如下 智能移动设备通过近场信道获取文件加密的密钥初始化消息,包括文件系统访问地址URI及 a 通信密钥CommuniceaionkKey,其数据结构如下 tionReguest; SEQUENCE Eacrypt PrintableStri tag ring UTF8String(Size(1...MAX))， uri communicationKey KeyType 文件加密的密钥初始化消息中各个域的含义如下 ag域值为ENCRYPT,表示协议类型为文件加密 uri域为数据文件系统的通信地址 uwnicationkey域为用来保护通信内容的通信密钥,其数据结构如下 commt KeyType::=CHOICE accessKey [0]0CTETSTRING, pubKey [1]SubjeetPublickKeylnfo b 智能移动设备产生随机数作为内容加密密钥ContentKey,分别使用通信密钥Co ommunica tionkKey和文件接收者公制加密内容加密密钥Contenkey,得到密文和密文2,并通过 URI指定信道向文件系统发送文件加密的密钥传输响应消息,其数据结构如下 EncryptionResponse:;=SEQUENCE versionm Version cl BITSTRING c2 BITSTRING 文件加密的密钥传输响应消息中各个域的含义如下 11
GB/T40018一202 n域为文件加密响应消息的版本; version -el域为智能移动设备获得的通信密钥Co onkKey对内容加密密钥ContentKey ommunicatio 的加密结果 -2域为智能移动设备使用文件接收者公钥对内容加密密钥ContentKey的加密结果 文件系统接收到文件加密的密钥传输响应消息后解密密文cl得到内容加密密钥 ContentKey,并利用ContentKey加密文件,同时将2与加密后的文件一起保存
该协议的典型应用场景参见C.5
7.2文件解密密钥传输协议 本协议规定了利用智能移动设备的密码模块为文件系统提供密钥进行文件解密的过程,协议流程 见图8
a近场信道获取简单文件解密内容 bURI指定信道 发送简单文件情文请求消息
得到加密 sUR指定信道 老销，解摇 智能移动设备 文件系统 发送简单文件语文响应消息 文件 4R指定信道 发送简单文件解精啊应消息 图8文件解密密钥传输协议流程图 文件解密密钥传输协议流程如下 智能移动设备通过近场信道获取文件解密内容,包括文件系统访问地址URI及通信密钥 a ationkey,其数据结构如下 ommunicat DeryptionCipherContent;-sEQUENCE PrintableStrin tag ing urI UTF8String(Size(1..MAX)). communicationKey KeyType 文件解密内容中各个域的含义如下 ag域值为DECRYPT,表示协议类型为文件解密; uri域为数据文件系统的通信地址 communieationkey域为用来保护通信内容的通信密钥,其数据结构如下 KeyType;=CHOICE [o]0cTETSTRING. accessKey [1]SubjectPublieKeylnfo pubKey b)智能移动设备通过URI指定信道向文件系统发送文件解密的密钥传输请求消息,其数据结构 如下: DecryprtionCipherRequest:=sEQUENcE version version 文件解密的密钥传输请求消息中version域为消息的版本号
文件系统接收到文件解密的密钥传输请求消息后,通过URI指定信道向智能移动设备发送文 12
GB/T40018一2021 件解密的密钥传输响应消息,主要包括用户公钥对内容加密密钥ContentKey的加密密文2 信息,其数据结构如下: DecryptionCipherResponse::=SEQUENCE《 BITSTRING 文件密文的密钥传输响应消息中四域表示用户公钥对内容加密密钥conenuKey的加常 密文
智能移动设备接收到文件解密的密钥传输响应消息,使用用户公钥对应的私钥解密c2,得到 内容加密密钥ContentKey,并使用通信密钥CcommuniceationkKey加密ContentkKey得到密文 cl
智能移动设备通过URI指定信道向文件系统发送文件解密的密钥传输回复消息,其数据 结构如下 ::=SEQUENCE DeeryptionCipherReply BITSTRING cl 文件解密的密钥传输回复消息中cl域为通信密钥Communiceationkey对内容加密密钥Cont entKey的加密结果
文件系统援收到文件解密的密钥传输回复消息后,解密al得到内容加密密钥ContentKey,并 使用contentKey解密文件密文,得到文件明文 该协议的典型应用场景参见c.6
13
GB/T40018一2021 附 录 A 资料性附录) 兼容性分析 用途 A.1 本附录主要分析本标准定义协议与现有应用协议的兼容性
A.2兼容性分析 目前二维码携带的信息通常为一个URI,URI的格式为:[scheme:][//authority][path [" query，可以通过scheme来区分不同用途的二维码
本标准中二维码的内容也采用了URI格式 使用TAG作为scheme区分不同的应用场景,具体为 -TAG为CERT,按照第5章协议进行证书申请 TAG为AUTH,按照6.1.1协议进行身份鉴别: TAG为SIGN,按照6.1.2协议进行信息内容数字签名; -TAG为AVERIFY,按照6.2.1协议进行身份鉴别的数字签名验证; -TAG为CVERIFY,按照6.2.2协议进行信息内容数字签名验证; TAG为ENCRYPT,按照7.1协议进行文件加密; -TAG为DECRYPT,按照7.2协议进行文件解密
14
GB/40018一2021 录 附 B 资料性附录 采用二维码的证书申请协议 B.1用途 本附录给出了证书申请中的一种模式,即近场信道基于二维码的证书申请示例
应用场景为通过 手机向证书认证系统申请证书
B.2采用二维码的证书申请协议 采用二维码进行证书申请的具体流程如下: 证书认证系统生成证书申请登记报文ApplyCertificeateRegistration对应的二维码:首先对 a ApplyCertifieateRegistration结构体进行DER编码,然后将编码结果通过BASE64转换成可 打印的字符串CONTENT,然后加前缀CERT://,系统生成二维码; b 手机通过扫码获取CERT://CONTENT,并解析cONTENT获取证书认证系统生成的证书 申请登记报文ApplyCertifieateRegistrations 手机生成随机验证码Verificationm nCode并展示给用户; d 手机通过网络信道向该URI所在的证书认证系统发送证书申请请求消息; 证书认证系统接收到手机的请求消息后,显示输人界面,要求用户输人c)中手机所生成的 Verificat ationcode;证书认证系统对手机的证书申请请求消息进行验证,包括验证RN SessionlD是否有效;用户签名公钥验证签名是否正确;厂商ID是否在可信厂商列表中,厂商 私钥对RN的签名是否有效; 证书认证系统通过网络信道向手机回复证书申请响应消息 用户可按照GM/T0014一2012要求下载证书,也可通过近场信道获取证书下载消息
证书 g 下载二维码的TAG为DOwNLOAD,URI为证书下载服务的地址
15
GB/T40018一2021 录 附 C 资料性附录) 应用场景 C.1用途 本附录对标准中数字签名与验签协议,文件加解密协议的典型应用场景进行介绍
C.2用于身份鉴别的数字签名协议应用场景 该协议的一种典型应用场景是智能门锁,可用于智能门锁对用户身份进行鉴别
协议开始前用户 的公钥信息已在提供身份鉴别服务的业务系统中完成注册,具体流程如下 用户选择通过智能移动设备进行开锁,智能移动设备通过NFC获取业务系统的网络访问地址 a URI,RN,SessionlD,业务系统描述信息等信息; b 智能移动设备显示a)中获取到的URI及系统描述信息,要求用户进行确认,确认通过后向业 务系统发送身份鉴别请求消息; 业务系统收到身份鉴别请求消息后进行验证,验证通过后打开智能门锁
C.3 信息内容数字签名协议应用场景 -种典型应用场景是对网上交易内容进行签名,具体流程如下 该协议的- 用户使用智能移动设备扫描二维码,获取提供交易内容业务系统的访问地址URI和访问令牌 a 信息AeessCode: b 智能移动设备通过网络信道向业务系统发送获取交易内容请求消息; 业务系统通过网络信道向智能移动设备发送交易内容 c 智能移动设备向用户显示签名内容,用户确认对显示内容进行签名后,智能移动设备将内容签 d 名结果通过网络信道发送至业务系统
C.4信息内容数字签名验证协议应用场景 该协议的一种典型应用场景是证件验证,具体流程如下 用户使用智能移动设备扫描证件二维码,获取与证件验证系统通信方式为NFC以及访问令牌 a 信息AceessCode; 智能移动设备通过NFC向证件芯片发送证件内容签名验证请求消息; b 证件芯片收到鉴别请求消息后首先验证AecessCode合法性,验证通过后对证件内容进行签 c 名,同证书下载地址或证书一起发送给智能移动设备 d 智能移动设备提取证书或根据下载地址下载证书,验证签名值是否有效
C.5文件加密的密钥传输协议应用场景 该协议的一种典型应用场景是邮件内容加密,协议开始前用户已将邮件接收者的公钥信息导人到 16
GB/40018一2021 智能移动设备中,具体流程如下: a 邮件系统发送邮件内容前,生成二维码,用户使用智能移动设备扫描二维码获取邮件系统访问 地址URI及通信密钥Communicationm nkey b 智能移动设备产生随机数作为内容加密密钥ContentKey
分别使用通信密钥Co Ommunica- ionKey和邮件接收者公钥加密内容加密密钥ContentKey,得到密文cl和密文c2,并通过网 络信道发送至邮件系统; 邮件系统接收到数据后解密密文cl得到内容加密密钥ContentKey,并利用ContentKey加密 文件,同时将e2与加密后的文件一起发送至邮件接收者
C.6文件解密的密钥传输协议应用场景 该协议的一种典型应用场景是邮件内容解密,对应C.5邮件内容加密流程,具体流程如下 邮件接收者点击邮件内容,邮件系统生成二维码,接收者使用智能移动设备扫描二维码获取邮 件系统访问地址URI及通信密钥CommunieationKey; b 智能移动设备通过网络信道向邮件系统发送文件解密的密钥传输请求消息 邮件系统接收到文件解密的密钥传输请求消息后,通过网络信道向智能移动设备发送用接收 者公钥对内容加密密钥ContentKey的加密密文c2; 智能移动设备接收到文件解密的密钥传输响应消息,使用加解密密钥对中的私钥解密2,得 到内容加密密钥ContentKey,并使用通信密钥CommunicationKey加密ContentKey得到密 文cl,通过网络信道将c1发送至邮件系统 邮件系统接收到cl数据后,解密cl得到内容加密密钥ContentKery,并使用contentKey解密 文件密文,得到文件明文
17
GB/T40018一2021 考文献 参 [1]GB/T34095一2017 信息安全技术用于电子支付的基于近距离无线通信的移动终端安全 技术要求 tehmology -AbstractSyntaxNotationOneASN.1 [2]ISO/IECDIS8824-1lnformmation" Part Specifeationofbasicnotation 18
信息安全技术基于多信道的证书申请和应用协议GB/T40018-2021
GB/T40018-2021是我国信息安全领域新出台的一项标准，其提出了一种基于多信道的证书申请和应用协议技术。相较于传统证书申请方式，基于多信道的证书申请更为安全可靠。
该协议技术采用了多信道进行通信，避免了单一渠道带来的风险。同时，协议中还使用了双因素认证、加密等多种安全机制，保障了证书申请和使用过程中的安全性。
在实际应用中，GB/T40018-2021可以广泛应用于各类数字证书的申请和使用，如SSL证书、数字签名证书等。通过使用该协议技术，可以有效提高数字证书的安全性和可信度。
总之，GB/T40018-2021是一项非常有前途的信息安全技术，其基于多信道的证书申请和应用协议在实际应用中将会发挥越来越重要的作用。
