密评：能力验证

Jasioniso

已于 2024-07-25 14:35:58 修改

阅读量1.4k

点赞数 12

分类专栏：密评文章标签：安全

于 2024-04-08 14:38:26 首次发布

本文链接：https://blog.csdn.net/weixin_46849758/article/details/136910866

版权

密评专栏收录该内容

8 篇文章 35 订阅

订阅专栏

1.简要介绍

随着商用密码应用安全性评估的快速发展，越来越多的密码从业人员参与其中，并先后取得了商用密码应用安全性评估从业人员的资格证书，为我国网络空间和信息安全奠定了坚实的基础。自2020年1月1日，《中华人民共和国密码法》正式实施以来，以法律的名义勾勒出了“以密码技术为核心、多种技术交叉融合的网络空间新安全体制”的清晰蓝图。

其中商用密码应用安全性评估试点机构（简称“测评机构”）更是向着更好，更快的方向发展。从先前的（2020年7月30日）国家密码管理局公告（第40号）公布的24家测评机构试点目录，到后来的（2021年6月11日）国家密码管理局公告（第42号）增至到48家测评机构试点目录，此外，为适应特殊情况和个别地区又新增了25家省内的测评机构（没有资质，只能省内开展密评业务）。此时共计48（全国试点）+25（省内0）家机构，如下图（25家省内机构不画入其中）：

2024年3月26日，按照《商用密码管理条例》、《商用密码检测机构管理办法》有关规定，国家密码管理局组织对商用密码检测机构（商用密码应用安全性评估业务）资质申请材料进行了审查，并将通过材料审查的机构名单予以公示。其中第三批申请密评机构的数量达到了155家，其中110家为等保机构，如下图：

能力验证可能需要到的在线工具

①验签
https://www.btool.cn/ 分享个在线工具，还挺好用的

②UrlEncode在线URL网址编码、解码：
https://www.qianbo.com.cn/Tool/Url-Encode.html

③RSA在线加密/在线解密
https://the-x.cn/zh-cn/cryptography/Rsa.aspx
④公私钥PKCS格式转换
https://www.ssleye.com/ssltool/pkcs.html#

⑤MD5 在线HASH加密
https://crypot.51strive.com/

⑥在线SHA加密工具:SHA1加密，SHA256加密，SHA512加密
https://www.gseen.com/online_tools/encryption/sha

2.能力验证

2.1TLS协议分析

那么，我们接下来就以2020年的密评真题为例，进行进一步的学习和理解，以帮助更多的人或申请机构去面对接下来的密评能力验证，网络拓扑图如下图所示：

① 以网络层面为例：数据流量包在这块具体的抓取不在进行相应的描述，在分析N1的数据流量包时，需要关注Service Hello里面的信息，用于区分是否是双向鉴别还是单项鉴别，然后查看里面的算法套件、数字证书等配置信息，如下图所示：

也许在密评这块相应的证据已经取完了，但是对于一个密码从业人员来说，针对TLCP这块，我们还需要进行进一步的学习和了解。其中，TLCP就是国密SSL协议，在Client Hello里面会有相应的协议的版本号（TLS协议定义有三个版本号，为0x0301、0x0302、0x0303，分别对应TLS 1.0、1.1、1.2。国密SSL为了避免冲突，选择了0x0101。国密SSL协议规范是TLS 1.1和TLS 1.2的混合体，大部分情况下参考TLS 1.1，少数地方又参考了TLS 1.2。）

客户端（Client Hello）所传输的随机数（4字节的时间戳+28字节的随机数），如下图所示：

服务端（ Service Hello）同样也会生成一个32字节的随机数，如下图所示：

2.1.1算法套件

关于算套套件这块的详细描述已在另外一篇文章中描述，详情请见：密评：TLS协议与密码算法的关系_当使用aes-gcm与sha384同时存在时-CSDN博客，为了便于理解，这里见下图：

关于TLS1.0，TLS1.2协议的算法套件，这块想必从事密评的工作人员已经非常清楚了，那么接下来我们就来看一下TLS1.3协议所支持的算法套件，需要注意的是：TLS1.3协议直接换掉了密钥交换算法和身份验证算法，后面直接跟这个对称的加密算法、强度、工作模式。如下图：

2.1.2数字证书

接下来我们来看一下GB/T 20518-2018《信息安全技术公钥基础设施数字证书格式》这个标准，里面详细说明了怎么去区分，加密证书和签名证书，需要注意的是：如果是TLS1.3协议，可能数据流量包里面只有一个数字证书，里面包含了a）b）c）d）（签名证书和加密证书二合一），如下图：

然后，我们来看一下服务器端密钥交换消息（Service Key Exchange），用于客户端计算产生48字节的预主密钥，如下图：

2.1.3ECC密钥交换

当密钥交换算法是ECC时，具体的过程如下：

然后我们按照上述的方式把所需要的信息记录到记事本中，以便于后面操作，需要注意的是不要忘记了服务器端加密证书的长度000225，如下图所示：

然后我们通过验签工具，进行验签，大家可以通过这个在线工具进行验签：https://www.btool.cn/ 分享个在线工具，还挺好用的，如下图：

为了便于同行操作，我已将数据整理到下面：

签名证书公钥（做验签之前去除空格）：
04 49 a0 97 5f a5 32 95 d2 45 5b dd 5e f2 5d 5b d7 30 ba 76 34 3b 5c 2c 7e 7f eb 7e e0 be bf ad 0f 0f 1f 76 a6 3b 91 5a 00 86 fc 60 cc 6b 84 40 d3 f5 04 1b 54 42 2b eb d3 d4 66 4e f3 1d aa ef 5e

----------------------------------------------------------------------------------------------

Client Hello随机数：转换成16进制：
f81ce4d345466f00852fd30dc0555086544391bd2bd0ca13b8b66776a0bbc2ab

Service Hello随机数：转换成16进制：
5ed8968e7d19162fdc1aca131ddf438b55275de556c9994a8ff3bb871393d4cd

服务器端加密证书长度（3字节）+加密证书转换成16进制：
Certificate Length：549 → 000225 转换成16进制

----------------------------------------------------------------------------------------------

30820221308201c6a003020102020108300a06082a811ccf55018375308187310b300906035504061302434e3110300e06035504080c074265696a696e673110300e06035504070c074265696a696e67310d300b060355040a0c04424a4341310d300b060355040b0c04424a43413116301406035504030c0d424a4341534d32544553544341311e301c06092a864886f70d010901160f737570706f727440626a63612e636e301e170d3230303531323035313231345a170d3330303332313035313231345a30818e310b300906035504061302434e3110300e06035504080c074265696a696e673110300e06035504070c074265696a696e67310d300b060355040a0c04424a4341310d300b060355040b0c04424a4341311d301b06035504030c14626a6361736d3273657276657273727031656e63311e301c06092a864886f70d010901160f737570706f727440626a63612e636e3059301306072a8648ce3d020106082a811ccf5501822d03420004a0e54d33742636210e37a36c6e0102c296813a1812d112e44864337d7a248a6865afe51abf3830971465bdcbc9b003c72e62e0c7ca6ce53cf56f265ae877c442a31a301830090603551d1304023000300b0603551d0f040403020430300a06082a811ccf5501837503490030460221009dd093c169af50fbca6061ed1b10d4394b2768d115027f64533f24080d94f20d022100cc96806594a6ad537b78991c6e673384ef415da8c0d226103dcee21327341032

----------------------------------------------------------------------------------------------

签名值（ServicekeyExchange-Signature）转换成16进制：

3045022100e4795b5a947526f8e7cbd0edd571ea8749e0efd24323799346ea2c740c006c5a0220026189e51c19d20d40a82606d0ed72cb9530a189bbb94c09e4559d7d8ff3f598

Client Key Exchange
预主密钥：
30819a022100c8c1c8aa99126cb977bff495d232d45ee8a005ae043675f9033ab4fe80fe74da022100eb773e910262bf194cc3499cc3217953b457d6636af05ef19faeee41fc546927042080d71a10d30a0f5baaf13155c99914ef6e326fbbb72ed2078e6494a1c07d715c0430e9c49e7788943d9b6d781c823d4ab4274bbcca5206d7572b8c3c3afb04bf3961a58d51c6b25bd4f9751fabe94f349235

好的，到这里我们已经初步算是完成了第一步。然后我们接着往下看如果Client Key Exchange里面的信息，里面包括预主密钥，如下图：

然后我们将加密的预主密钥放到ASN1的解析工具里面可以看到，如下图：

2.1.4ECHHE密钥交换

其中ECC和ECDHE在协商预主密钥的方式是不同的，ECC是客户端直接生成预主密钥，ECDHE需要客户端与服务器端进行协商，下面是ECDHE进行密钥交换的原理，这里不再进行详细的描述，如下图：

2.2IKE协议分析

②接下来我们来分析N2数据流量包，需要关注的是Isakmp协议的主模式（Main Mode）以及相应的配置文件等信息，然后分析数据流量包里面的算法套件和数字证书，如下图所述：

在解析数字证书时，此流量包可以导出两张证书，但是两个证书的密钥用法是一样的，这块应该是数字证书配置问题，我们这块K给到不符合也是可以的，如下图：

③接下来我们来看一下，远程管理终端对应用服务器进行远程管理的通信数据流量包，分析SSH协议的版本和相应的算法套件，如下图所示：

这个分析过程对于密评从业人员来说，可以说是相当熟悉的了，这里不再进行详细描述，如果想要继续了解TcpDump工具的抓包过程，或者想要继续深入研究SSH协议里面的算法套件怎么更换（比如说：把高风险的算法套件更换成中低风险的算法套件）可以参考我的这篇博客：密评：TCPdump抓包教程以及修改SSH协议算法套件_tcp抓包数据修改-CSDN博客

2.3SSH协议分析

然后我们接下来来扩展一下国密的SSH协议有关内容，（国密SSH→CSSH协议）如下图所示：

2.4应用层面身份鉴别

接下来我们来看应用和数据安全层间的数据采集，尤其是身份鉴别指标的判定，我们作为一个密评从业人员，在测评这一块的时候，首先应该想到的是看一下身份鉴别的方式是什么？Ukey有没有数字证书？Ukey符不符合二级模块（产品认证证书）？等等这些问题，然后我们接着来看测试用户1的身份鉴别。

题目中给到的信息是测试用户1智能密码钥匙里面给到了RSA和SM2（双证书）的数字证书和证书链，经验证该RSA和SM2（双证书）数字证书均可以验证通过。

那我们需要确定登录过程中到底是用了哪个证书做了签名和操作。然后我们来看一下应用服务器的日志文件，我们可以看到通过服务器密码机对账户信息做了一个SHA1（输出20字节）的杂凑，如下图：

然后我们来看一下数据流量包进行进一步的分析，需要注意的是：MII=（base64）转换为16进制是（3082）如下图：

我们通过Wireshark可以使用这两种方式来搜索，其实原理是一样的，如下图：

另外的话我们可以通过POST请求直接筛选，但是这样子只能够看到客户端发送给服务器端的关键数据包，我们将复制保存到记事本中，然后将.txt文件保存为.cer文件即可，如下图：

如果是追踪TCP流，搜索关键信息MII后，再复制到复制保存到记事本中，然后将.txt文件保存为.cer文件，需要进行一下转义字符，如下图：

这样手动转换比较耗费时间，我们可以通过UrlEncode - 在线URL网址编码、解码这个现在解码工具进行解析，然后将解码之后的文件保存的.txt文件中，然后改成.cer文件即可（证书不再进行演示），如下图：

然后我们最后来看一下数字证书的另外一种编码格式（PEM），如下图：

好的，说到这里，相比大家都对数字证书的格式有了一定的了解，然后我们具体来看一下数字证书的验签，之所放到这里进行验签，是为了通过上面讲解的过程，更加便于我们的理解，那么我们先从RSA数字证书验签开始，如下图：

我们通过ASN1解析工具可以解析出公钥的（n，e），如下图：

然后我们通过Wireshark工具进行POST请求操作就可以看到如下信息，如下图：

我们将上面的消息记录到记事本中，需要注意的是：这个RSA数字证书的公钥需要转换成.pem的格式，以便于后面的验签操作，.cer文件的公钥转换成.pem的形式可以使用这个在线工具：RSA在线加密/在线解密公钥加密,公钥解密,私钥加密,私钥解密 - The X 在线工具，如下图：

为了便于操作，我已将数据整理到下面：

RSA数字证书公钥：
30 81 89 02 81 81 00 de 72 a0 aa 43 26 21 7c c5 da 03 93 f1 04 de b5 e9 e7 9e 8b a9 05 96 80 1f b8 53 02 36 0d b5 d5 4d bb d2 4d 8f 22 4a 7f 83 fa fa 0f b2 be ee e6 92 1f e3 04 e4 06 f0 f5 cb 94 62 df 8e 3f 98 f3 62 51 4e a7 fa 6e 62 50 15 07 34 a9 ff 6c 90 19 b6 8e 16 21 1b de 95 44 73 fb b5 4c 3d 33 47 4e a0 e5 05 dc 31 40 27 a9 7d a9 3f 67 ef cb b3 9f 46 93 39 b3 2d 56 22 72 f5 88 cd f5 e9 a4 0b c7 02 03 01 00 01
这是.cer文件需要转换成.pem的格式：（PKCS#1格式）
MIGJAoGBAN5yoKpDJiF8xdoDk/EE3rXp556LqQWWgB+4UwI2DbXVTbvSTY8iSn+D
+voPsr7u5pIf4wTkBvD1y5Ri344/mPNiUU6n+m5iUBUHNKn/bJAZto4WIRvelURz
+7VMPTNHTqDlBdwxQCepfak/Z+/Ls59GkzmzLVYicvWIzfXppAvHAgMBAAE=
（PKCS#8格式）：
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDecqCqQyYhfMXaA5PxBN616eee
i6kFloAfuFMCNg211U270k2PIkp/g/r6D7K+7uaSH+ME5Abw9cuUYt+OP5jzYlFO
p/puYlAVBzSp/2yQGbaOFiEb3pVEc/u1TD0zR06g5QXcMUAnqX2pP2fvy7OfRpM5
sy1WInL1iM316aQLxwIDAQAB
------------------------------------------------------------------------------------------------
签名值（原始值）：

eZLugxFci8qBdZDk2%2BKHRLhetWeIbgxOYtPjB%2FNc0P6UMnLLC3UPEADf%2F7hA%2B4qZ69b2FuohOEFML2Yy7Kryfr5A2XOQrBiz7%2B5U%2FPWW%2F3K35LRZqh1WVZc75pAnbrK14STUxwGSUCTZfLqC5U9Y1F56Y3BPHs5cWvDkQEZlFTc%3D
Base64：
eZLugxFci8qBdZDk2+KHRLhetWeIbgxOYtPjB/Nc0P6UMnLLC3UPEADf/7hA+4qZ69b2FuohOEFML2Yy7Kryfr5A2XOQrBiz7+5U/PWW/3K35LRZqh1WVZc75pAnbrK14STUxwGSUCTZfLqC5U9Y1F56Y3BPHs5cWvDkQEZlFTc=
16进制：
7992ee83115c8bca817590e4dbe28744b85eb567886e0c4e62d3e307f35cd0fe943272cb0b750f1000dfffb840fb8a99ebd6f616ea2138414c2f6632ecaaf27ebe40d97390ac18b3efee54fcf596ff72b7e4b459aa1d5655973be690276eb2b5e124d4c701925024d97cba82e54f58d45e7a63704f1ece5c5af0e44046651537

--------------------------------------------------------------------------------------------------
签名消息（原始值）：
whMQOag0Gc2kVe%2BxEwHnQvXhCrOGu%2BBg
Base64：
whMQOag0Gc2kVe+xEwHnQvXhCrOGu+Bg
16进制：
c2131039a83419cda455efb11301e742f5e10ab386bbe060

签名消息（原始值str）：
whMQOag0Gc2kVe+xEwHnQvXhCrOGu+Bg
Base64：
d2hNUU9hZzBHYzJrVmUreEV3SG5RdlhoQ3JPR3UrQmc=
16进制：
77684D514F6167304763326B56652B784577486E5176586843724F47752B4267

需要注意的时，整理完这些信息之后，我们发现上面的数字证书的公钥转换成.pem格式之后与我们下面的这个工具输入的密钥不一致，这是因为通过上面在线转换工具转换完之后是PKCS#1的格式，我们需要转换成标准的PKCS#8的格式，我们可以通过这个在线工具来实现（SSL在线工具-在线RSA公私钥格式转换|公钥PKCS1与PKCS8转换|私钥PKCS1与PKCS8转换-SSLeye官网）当然，如果大家没有我们这个验签工具的话，也可以通过我上面所说的这个工具来进行验签操作（在线RSA验签工具 - BTool在线工具软件，为开发者提供方便。）这个在线工具里面就可以使用PKCS#1格式，但是需要注意相应的格式选择，如下图：

同理，测试用户2所使用的SM2数字证书证书验签过程如下图（这里不在进行详细讲解，步骤和RSA验证类似），如下图：

为了便于操作，我已将数据整理到下面：

SM2数字证书公钥：
04 db d5 1b ad a3 8b 08 77 e5 bf 63 ee 8c 1d bc 4b c4 93 8b 7b f5 70 97 47 26 5e ea 23 aa e7 98 cf 06 16 5a 49 bc 11 5b d3 16 6c bc c7 8d 95 75 5a 39 11 a9 2a 6c 2f bf b3 42 87 ae b8 cd 71 a3 e4
这是.cer文件需要转换成.pem的格式：
MFkwEwYHKoZIzj0CAQYIKoEcz1UBgi0DQgAE29UbraOLCHflv2PujB28S8STi3v1
cJdHJl7qI6rnmM8GFlpJvBFb0xZsvMeNlXVaORGpKmwvv7NCh664zXGj5A==
------------------------------------------------------------------------------------------------
签名值（原始值）：
MEQCIC97dyd4S6GrljmFrVd71xICb6RRQhsH3%2FB%2B7xEWLMczAiAfIG8ZIXVXf5zMzoN31yM8F3s5vM7TcXoag%2FVNZ3E0yw%3D%3D
Base64：
MEQCIC97dyd4S6GrljmFrVd71xICb6RRQhsH3/B+7xEWLMczAiAfIG8ZIXVXf5zMzoN31yM8F3s5vM7TcXoag/VNZ3E0yw==
16进制：
304402202f7b7727784ba1ab963985ad577bd712026fa451421b07dff07eef11162cc73302201f206f192175577f9cccce8377d7233c177b39bcced3717a1a83f54d677134cb
---------------------------------------------------------------------------------------------------
签名消息（原始值）：
0d15n6eNicflfHucOvsTah5Q5NvgOU5T

Base64：
0d15n6eNicflfHucOvsTah5Q5NvgOU5T
16进制：
d1dd799fa78d89c7e57c7b9c3afb136a1e50e4dbe0394e53

签名消息（原始值str格式）：
0d15n6eNicflfHucOvsTah5Q5NvgOU5T
Base64：
MGQxNW42ZU5pY2ZsZkh1Y092c1RhaDVRNU52Z09VNVQ=
16进制：
306431356E36654E6963666C664875634F76735461683551354E76674F553554

2.5重要数据传输的机密性和完整性

接下来我们通过Wireshark工具来看一下测试用户1所传输的数据（明文传输），同理，测试用户2的重要数据在传输是也为明文传输（这里不再放图，分析方法和测试用户1一样），如下图：

2.6重要数据存储的机密性和完整性

2.6.1口令、手机号、身份证号

在分析这一块的时候，先说明一下重要数据存储机密性所分析的数据是（口令、身份证号、手机号），重要数据存储的完整性所分析的数据是（口令、身份证号、手机号、测试用户1关键数据操作信息、测试用户2关键数据操作信息、用户角色、权限信息）。

然后我们来看一下用户数据表，我们可以通过字符串统计工具进行数据分析（MD5在线HASH加密-在线工具），可以的到用户口令为16字节，初步判断为MD5算法，如下图：

然后我们去找个在线的验证工具去验证一下（测试用户2同理，这里只以测试用户1为例），如下图：

接下来我们来看一下手机号是8字节，不符合SM4分组长度16字节整数倍，符合3DES（分组长度8字节）特征，然后我们再查看密钥表中的密钥类型和64比特的密文，推测出手机号可能是由3DES加密，如下图:

然后我们接着来分析身份证号，通过用户数据表我们可以知道手机号长度是32字节，符合SM4分组长度16字节的整数倍，当然也符合3DES（分组长度8字节）的特征，那么我们在通过密钥表进行解析时，是无法确认到底用了3DES进行加密，还是用了SM4进行加密的，因此我们需要进一步确认，我们可以通过查看应用服务器的配置信息，发现里面调用了SM4的密钥的密文，并且加密成功，如下图：