编者按：2024年4月15日，是我国第九个全民国家安全教育日，今年的活动主题是“总体国家安全观 创新引领10周年”。“没有网络安全就没有国家安全”，密码是国家重要战略资源，是保障网络与信息安全的核心技术和基础支撑，是保护国家安全的战略性资源。为积极贯彻落实《密码法》，秦商密隆重推出《深入浅出》和《自己动手》原创技术科普系列，旨在普及商用密码知识，培养密码应用创新人才。今日更新《自己动手》系列第四篇：能力验证与密评工具-身份鉴别（一），本系列文章旨在抛砖引玉，如有不足之处，请各位专家不吝珠玉！
网络与通信层身份鉴别
情景1：
2020年商用密码应用安全性评估能力验证题目-网络与通信层身份鉴别：“远程办公用户（A1）使用专用的SSL VPN客户端通过SSL VPN网关（C1）登录到单位内网。每次网络接入时，在用户和SSL VPN之间完成双向鉴别，同时通信数据在互联网流转时进行了机密性和完整性保护。”
Ⅰ.使用工具：
①数字证书分析工具
②TLCP报文验签工具
Ⅱ.步骤：
①从Server Hello报文中导出SSL VPN的签名证书：可由公钥长度分析出证书对应的公钥是SM2证书、核对密钥用途、时间编码规则、CRL校验、起止日期等是否合规：涉及指标——D, A；
②TLCP协议的Server Key Exchange报文中有一个签名值：Sign{客户端随机数|| 服务端随机数 || 加密证书长度 || 加密证书值}；作为鉴别数据。这个签名值是可以被验证的，我认为测评人员对该签名值进行验证，可以作为签名证书被正确、有效使用的主要证据；同时可以保护加密（用于密钥交换）证书的真实性，作为通信过程中重要数据传输测评单元的辅助证据。
该签名的构造结构如下：
将数据填入TLCP快速验签工具中，TLCP快速验签工具允许测评人员直接从加密扩展外壳中复制带04头和空格字段的公钥内容；
该步骤涉及测评指标——D, A；
③2020应用方案中双向鉴别的SSL VPN.，在实际情况中使用的是单向鉴别；DAK指标应该判为：××× —— 0（一条通信信道视作一个测评对象）另外，关于这条的风险评估，应该是高风险；【这里可能存在的异议是：由通信信道报文抓包分析可得：客户端对服务端进行了身份鉴别且符合性为：√√√ 而服务端没有对客户端进行身份鉴别：×××，故量化评估得分为：—— 1 / 2 = 0.5（客户端与服务端相互鉴别视作两个对象）——我个人反对这种测评方法：因为1.双向鉴别本就是四级信息系统与三级信息系统之间的重要指标区别；2.网络与通信层面的测评对象是通信信道；】
④核对密码产品的商用密码认证证书：
该步骤涉及指标：——K；
应用与数据层身份鉴别
情景1：
2020年商用密码应用安全性评估能力验证题目-应用与数据层身份鉴别：远程办公用户（A1）与分支机构用户（B1）都配发了智能密码钥匙（KA和KB），智能密码钥匙中存放了基于SM2算法的证书。用户登录应用前，都需要利用该智能密码钥匙，进行“口令+证书”的双因素身份鉴别后方能访问应用。
应用服务器（D1）调用签名验签服务器（D2）在用户登录时对用户的证书和签名进行验证。
Ⅰ.使用工具：
①数字证书分析工具
②证书链分析工具
③签名验证工具
④数据格式转换工具
Ⅱ.步骤：
测评对象远程办公用户A1：
①从测试用户1（远程办公用户A1）登录和操作过程中应用服务器和用户终端之间的通信数据中导出登录过程中使用的数字证书：C1.cer；
②从智能密码钥匙中导出远程办公用户A1的证书C11.cer、从测试用户1登录应用时签名验签服务器与应用服务器通信报文中导出C111.cer；核对C111.cer、C11.cer、C1.cer是否是同一张证书（主要核对证书序列号——不核对证书指纹的原因是）；
该步骤涉及测评指标——D, A；
③导出远程办公用户A1的证书C11.cer所属的证书链，验证证书链签名的正确性、CRL合规性：
如上图：RSA证书通过Windows加密扩展外壳打开，可以自行关联验证证书链签名正确性以及证书撤销状态；题目中另一个测评对象：分支机构用户（B1）在登录应用系统时使用的是SM2证书，SM2证书链的签名正确性验证和CRL在线状态验证需要使用：证书链验证工具，见下图。
该步骤涉及测评指标——D, K;
④核查测试用户1登录过程中应用服务器的日志：
实施细则：
（1）从WireShark提取签名值：必须是字符串格式的Base64字符；
（2）将提取到的Base64-字符串当作Base64格式输入到格式转换工具，输出Hex_Byte；
（3）复制签名原文-Base64字符串，同时跟服务器日志中的原文信息做比对；
服务器日志中的原文值Hex_Bytes是：“c2131039a83419cda455efb11301e742f5e10ab386”；转为Base64的结果是：“whMQOag0Gc2kVe+xEwHnQvXhCrOG”，然而，报文中Base64字符串的内容是：“whMQOag0Gc2kVe+xEwHnQvXhCrOGu+Bg”，对应Hex_Bytes是“c2131039a83419cda455efb11301e742f5e10ab386bbe060”；下图做为对比：
验签的时候需要使用客户端发往服务端报文内携带的Base64字符串（增加u+Bg部分的）。比对服务器日志Hex与客户端发包Base64转Hex的理由是，确定客户端收到了来自服务端正确的挑战值，从而对其进行签名、实现服务端对客户端的身份鉴别；
（4）用加密扩展外壳打开证书，复制证书中的公钥；
（5）将公钥、原文、签名值输入到验证器中；然而，这里有一件很意外的事情：
公钥：复制自Hex字节
签名值：接收为Base64字符串，进行Base64编码后作为Hex字节格式输入验证器；
原文：接收为Base64字符串，经验签测试，该字符串作为Base64被编码后的字节会导致验签失败；而将其直接作为ASCII / UTF-8编码为字节输入到验证器中，可以验证成功。
（附：验证测试用户2的签名）
同样的，测试用户2登录时的Base64字符串也应当直接当作字符串对待，而不是以Base64编码后将让字节进入验证器。
此步骤涉及测评指标：D, A；
报文中Base64格式如何看待、代入运算
“whMQOag0Gc2kVe+xEwHnQvXhCrOG”，其表示的意思是：C2131039a83419cda455efb11301e742f5e10ab386——21个Hex字节，Base64编码的意义在于使其对用户可见。
但是，“whMQOag0Gc2kVe+xEwHnQvXhCrOG”本身作为应用层字符串数据被传输出去的时候，即便被称为“Base64编码”，但其底层仍旧是一个字符对应一个字节的信息；本题中涉及大量应用层Base64编码字符串的传递、签名、加密、验证等信息。接收Base64编码的一方都没有将Base64字符串编码成其表示的字节进行运算，而是将其当作ACII字符串来对待，生成对应的签名、杂凑值等等。就比如这个：测试用户1登陆应用程序的挑战应答。
为何我认为此处可能存在问题？因为在用户行为不可否认性单元中，应用层http报文传递的Base64编码就被正确用于表示其对应的字节，并且这些字节可以被utf-8解码为用户操作行为信息：“2020-06-22 06:45:08:586 ceshiyonghu1 signs a contract.”（而不是上方遇到的那种直接当字符串用的情况）见下图：
签名值上面有一个键：data，将其Base64编码转换成utf-8格式，结果是：“2020-06-22 06:45:08:586 ceshiyonghu1 signs a contract.”这可能就是待验证的原文了
图 26 其他Base64内容格式转换示例
（END）
文中工具地址
https://mp.yh-w.cn/
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论