密码技术应该怎么用第十天！

    还是讲一下数据源的问题，数据源如果有问题，那么保护起来意义也就不大了，做事最好是从源头上解决问题，从源头保证数据的真实，完整，有效，将数据在采集的时候根据策略打上标签，那么后面就是根据标签来处理数据。这也是为什么我一直坚持，业务系统自己搞密码能力的重要原因。多扯一句为什么东大的股市不行，源头上就是蒸发货币和融资来使用，根上出现的问题，不是出几个政策就可以解决的。

   目前很多系统都是把数据收集到一起再进行数据的治理，而没有在采集，传输和存储的时候保证数据的质量，这样的治理浪费了大量的资源，按照二八原则，你懂的【多少数据安全产品，都是事后处理问题】，一个查漏补缺的作用，反而花了大价钱去搞。做什么系统二八原则都适用，我们应该集中精力去搞定最重要的源头问题，但是里面牵扯到的利益太多，或者甲方爸爸都不愿意从源头解决问题呢？！

    根据数据的重要情况可以选择硬件密码模块，或者自行研发的SDK，注意如果数据量不大，每秒k级，可以选择SIM卡密码模块。怎么提供加密性，完整性，真实性，之前已经讲过多次。推荐【SM4_CBC+HMAC，SM4_GCM】。

    如果只有口令【常说的密码passsword】，我们怎么办，给出一个简单的例子开通过口令生成密钥。以下给出一个样例，可以参照样例自己来搞一个，只要符合原则即可。下面的例子中可以不考虑SM2的密钥。对于规范上需要的带一百万次，看使用环境吧，想要盗取你的数据，跑设备上去搞的可能性很低，更有性价比的是社会工学！没有办法的情况可以使用此方式，总比裸奔好得多。这种方法需要保护好盐的安全。

• Password Based Encryption:基于口令密码

盐值至少8个字节，迭代次数至少1024，建议1000000次【一百万次】

1.使用随机数生成盐，盐需要安全保存Salt[36]=939f703c-2ed6-483a-8398-17116ac4e1cf

2.在Key 输入口令[11]=Encrypt@123

3.拼接SaltAndKey[47]=939f703c-2ed6-483a-8398-17116ac4e1cfEncrypt@123

4.排序后的SaltAndKeySort[47]=----0111112233333446677888999@Eaaccccdeeffnprty      

/*一般可以SM3 1024+次，SM3极快，基本不影响速度，可根据实际情况设置次数*/

5.第一次SM3[64]

=2524AF1F875AE320BB6AA9D0D099014F7B5D231430F9F0FCA04DEC418B16A22C

6.第二次SM3[64]

=D86010868FA4D87A2FFDA2025291617AD5AEDEDD1CC08A887FEBDB6DDF38CF6D

7.第三次SM3[64]

=2929918E51D6CD6356C83AA86AD7DC69044DE72DE8E868CC198B7DAE9D856774

8.密钥KeK1取第三次SM3左侧32个字符

KeK1[32]=2929918E51D6CD6356C83AA86AD7DC69

9.密钥KeK2取第三次SM3右侧32个字符

KeK2[32]=044DE72DE8E868CC198B7DAE9D856774

10.密钥KeK3取第三次SM3第16个字符开始获取32个字符

KeK3[32]=56C83AA86AD7DC69044DE72DE8E868CC

11.第四次SM3[64]

=2929918E51D6CD6356C83AA86AD7DC69044DE72DE8E868CC198B7DAE9D856774

12.密钥KeK3IV取第四次SM3左侧32个字符

KeK3IV[32]=388938AD8702A2B259F5BDB48AA0C80E

13.内容密钥CeK[32]=********************************

14.使用KeK3，KeK3IV,PKCS7填充,加密CeK结果Encrypted_CeK[96]

=EAE35E0FF6E91EB2C599BEE3478BFF4B1820FAD1E3A72A05AE4F53F1F84453BBF06940B9D3C9EB5D8564EDC7C0EFB510

15.生成的SM2公钥PubKey[128]

=A6430D9FA48AE463FCCB2FC32A54B0692B0A7627BF8608039F4A49CEE4ABB2E782C6CD54B5F19204DD8966E345FDAB779058218405A35DCEABFAAA2CA31EB990

16.生成的SM2私钥PriKey[64]

=****************************************************************

17.使用KeK3，KeK3IV,PKCS7填充,加密PriKey结果 Encrypted_PriKey[160]

=F53A68F7D3D002414F515FD7A79D5A5109D76C0BD990B798D828AA2AC115CAA2A03A4190A9899E14EC616EF53992A2DA7D7D6DA785AC8B4C2D9FF35B84471FA5EA993D7F3221058A67BF71AE9944B6B8

18.注意安全保存：Password，Salt，Encrypted_CeK，Encrypted_PriKey!

有了密钥两个实体之间怎么互信？

• 15843单项鉴别: 单步

IA的标识：假设为A100，IB的标识：假设为B100

A和B的共享密钥Key

Random：A产生的随机数，数据从A发送到B

1）对称密码：    TokenAB =IA||TS||Random||KeyAB(TS||Random||IB)  KeyAB 使用SM4-CBC，GCM

2）消息认证码： TokenAB= IA||TS||Random||MAC(TS||Random||IB)   MAC 使用HMAC-SM3

3)  数字签名：    TokenAB= IA||TS||Random||Sign(HASH(TS||Random||IB))) Sign 使用SM2，HASH使用SM3

|| 适用JSON或者其他连接符

IA 表示A实体发起的认证请求，IB的存在是为了避免此请求从B发送到A

其中TS，Random和KeyAB加密的TS，Ramdom 应该一致，TS在外面是方便校验，

和当前直接时间对比，超过约定时间之后直接拒绝，不用校验。

Random明文传输，TokenAB中有此因子，时间戳有效范围内（一般小于5分钟）超过时间后清理库中的随机数。

• 15843单向鉴别，两步

IA的标识：假设为A100，IB的标识：假设为B100

A和B的共享密钥Key

1.Random：B产生的随机数,A获取到B产生的随机数，再从A发送到B 【Random明文传递需要增加RandomA作为TokenAB的因子】

2.选择合适的方法生成TokenAB

1）对称密码：  TokenAB =IA||TS||RandomA||KeyAB(TS||RandomA|| RandomB||IB)  KeyAB 使用SM4-CBC，GCM

2）消息鉴别码: TokenAB= IA||TS||RandomA||MAC(TS|| RandomA||RandomB||IB)   MAC 使用HMAC-SM3

3)  数字签名：  TokenAB= IA||TS||RandomA||Sign(HASH(TS|| RandomA||RandomB ||IB))) Sign 使用SM2，HASH使用SM3

|| 适用JSON或者其他连接符。

IA 表示A实体发起的认证请求，IB的存在是为了避免此请求从B发送到A

其中TS，Random和KeyAB加密的TS，Ramdom 应该一致，TS在外面是方便校验，

和当前时间直接对比，超过约定时间之后直接拒绝，不用校验。

Random明文传输，TokenAB中有此因子，时间戳有效范围内（一般小于5分钟）超过时间后清理库中的随机数。

这基本是15843的实体鉴别的简便方式，有没有更好的方法呢，

一个接口实现双向验证

举个例子[SM4_GCM方式]：

参数如下：

key='2934412A66B7A186DC35DC40E926F9EE'

iv='86CD720D75F4622DBE96078A3CD1076E'

code = 'Hex'

可以使用Python提供SM4_GCM 验证一下

发起端：

plain_request：{'user_id': '18900000001', 'timestamp': '1736478558.836772', 'random': '71BC2F60AEADF363AC8ADF6C648BA6A7BA9405992DEEBD304128F17D221B83AD'}

req_aad:100001736478558.83677271BC2F60AEADF363AC8ADF6C648BA6A7BA9405992DEEBD304128F17D221B83AD

request_value: {'app_id': '10000', 'timestamp': '1736478558.836772', 'random': '71BC2F60AEADF363AC8ADF6C648BA6A7BA9405992DEEBD304128F17D221B83AD', 'encrypt_data': '3C2EECDADBBE991F283AEDC11695A366A0E64A1330421B740C2183E42B1C4C8287B6B88811D09911ABDEDE2E6A00ED8965F011184E3ACBAF7BD89049DACE8DFA00B5C1CA2873683F1268C4060E6FB649568A29F5B3FE6C0B0213D73D947F173A52E11615328D6498B74189B563321FCBC38B00EEB02D458D1C409D641DBF37DDBEA48D3CD9F1ED37F294E16912255B89', 'mac': 'BB1BE3503B52BA03651F2945F087B46A'}

说明：发起端使用SM4_GCM 方式发起验证，

验证端：1）时间戳是否在有效范围内

               2）是否可以解密，解密成功将随机数可以加入内存/数据库控制重复放

              3）业务处理

一个请求完成了验证端对发起端的，机密性，完整性和真实性【发起端身份】验证。

当然也可以使用SM4_CBC+HMAC, 之前已经刚讲过。密码技术应该怎么用第九天！-优快云博客

同样一个接口可以完成双向认证： 发起端样例见上面

IB【验证端】对IA【发起端】验证发起请求的合法性，验证端返回数据，见例子：

IA对IB进行验证，同样的验证方式，只要共享密钥安全，那么一个接口就可以实现双向鉴别！

返回参数

response_value：{'app_id': '10086', 'encrypt_data': '5B9DF7B556EC3D1A49428443E7804559CBB877F202D67CE9C5D5A2FB2C5857506C46958057E9A60A30ABBF5CF65AB6C39FA596595B5521D1AAD5F2A7028A5DD4471409E4EDEB71FF061EB84FCBF7E51B68893BFC2F9F9AA1ED278E30DB0575071778365E1D76FC5CD3C0E4975CC73AE7253EED305F0D8324184EFAB09310F05F62900A3D0FD544F897A7BD1B3F36E68A139FB8712D05248A22CEEDBEB7BE92ABCBEB45DD0B90759079F2C5702F806EFF11650274E172BA6FFFBA7DE6DAD312D2D0E53CB1B994E841044D2FFC6922871808D1A0E1C002112A301012E757E95E0DA78B59B8C376BD6A45FAC814CBFE175B', 'mac': 'B7653773AF71DCEB6084C31917862887', 'random': '18C54983DFDF8C94BE812D8A024C666301B4D20F16BEEC1ECB27D19659C39586', 'timestamp': '1736479925.86683'}

resq_tag：0A0059C59CEC8E5F0F018CAD3A302F8F

resq_aad:100861736479925.8668318C54983DFDF8C94BE812D8A024C666301B4D20F16BEEC1ECB27D19659C39586

验证结果：result_code=600

verify mac：True

response={'result_code': '600', 'app_id': '10086', 'user_id': '18900000001', 'user_name': 'Charlie', 'timestamp': '1736479925.86683', 'random': '18C54983DFDF8C94BE812D8A024C666301B4D20F16BEEC1ECB27D19659C39586', 'message': 'Query Sucess！'}