“家贼难防”系列-密钥硬编码

            越过昏晨线  便是永夜            

领导说我写的文章太枯燥，干巴巴的，看着犯困...

这不挺好嘛，至少有个催眠作用是吧，对于我这种夜猫子失眠患者，就需要这种文章啊，只能说领导没有进行需求调研！唉~既然领导提需求了，我得拒（lǎo）绝（shí）改！！！

好了，领导吐槽完事了，咱唠唠别的。

侃侃我老婆干的一次傻事吧（PS：迎合领导需求，把文章写“高大上”，喜欢干货的直接往下滑）。

我老婆记性不好，然后呢，总丢东西，据官方（我）统计，公交卡丢失4次，找回一次！然后这不是关键，关键的是她公交卡和门禁卡是放一个钥匙环的，上面还贴了哪栋哪个房间号，要论重要性，这也不是关键，关键是钥匙环上还有各种钥匙。。。

容我总结一下，就上面信息，捡到的人能干什么。。。

首先通过门禁卡上面的信息知道我家住哪；然后有了交通费，可以刷卡乘坐地铁公交啥的到小区；再然后有门禁卡，可以随便出入小区；再然后有钥匙，我家也可以随便进出，顺便带走点纪念品啥的。

要知道家里就一张门禁卡，丢失的东西比我手头上的还齐全，你说气不气。。。

好了老婆也吐槽完事了，咱引入正题，回到密钥管理上面来。

上面说到的场景其实就好比我们在手机移动端对密钥进行管理，在这里简单解释一下，在密码学中,密钥是指某个用来完成加密、解密、完整性验证等密码学应用的秘密信息。

这么说吧，就相当于保险箱的钥匙！

结合上面我老婆丢钥匙来说，在移动应用开发过程中，开发人员相当于我老婆（好像我吃亏了），丢钥匙这件事呢，就相当于开发人员密钥硬编码或者明文存储了。

那接着简单总结一下，就是开发人员代码实现了一个保险箱，然后呢，把钥匙放在保险箱旁边了，有的开发耍点小聪明，用桌布啥的遮一下（二次处理），有的直接放着（明文存储），一副“天下无贼”的感觉！

       道路千万条  密钥安全有三条       

为了使得密钥管理更加规范安全，需要做到以下三条，一般人我不告诉（活跃气氛，忽略）：

01

禁止密钥或认证凭证明文存储或硬编码保险箱的钥匙能带走就带走（服务端保存），不能带走的就找个别人拿不到的地方藏着（TEE、KeyStore或加密保存）。

02

密钥需要使用安全随机数生成钥匙如果做得跟铁棍一样，那也就失去了意义，一把合格的钥匙一定需要是独一无二的！所以密钥材料需要确保不可预测性，推荐使用安全随机数（不懂可以问问度娘）生成，长度需要满足加密算法强度要求（下次看情况跟大家唠唠），包括但不限于IV、salt等。

03

敏感数据需要加密传输或使用安全传输通道针对网络场景，若传输通道使用HTTP，敏感数据需要加密传输；使用HTTPS可明文传输敏感数据，不强制加密。讲白了就是加解密操作都是需要消耗时间和性能的，所以如果快递公司可靠，就没必要让快递员抱着保险箱来回跑了！

       自扫门前雪-本地密钥管理       

由于密钥管理一直是移动终端设备的难点，系统层面也为此做出努力，从安卓4.3版本后支持KeyStore密钥管理，Android提供的这个KeyStore最大的作用就是不需要开发者去维护这个密钥的存储问题，相比起存储在用户的数据空间或者是外部存储器都更加安全。

注意的是这个密钥随着用户清除数据或者卸载应用都会被清除掉，而且不可导出，所以并不适合有密钥共享需求的业务。

安卓7.0版本后系统引入了TEE，使得一些敏感操作和敏感数据可以得到保障，但这并不能对低版本用户提供帮助。

注：关于KeyStore和TEE这个我就抛个砖，想了解的筒子们跟度娘多熟悉熟悉她就会知道了。

  路见不平一声吼-基于客户端密钥上报方案  

   

方案说明

1. 客户端使用安全随机数生成用于对敏感数据保护的加密密钥；

2. 如果密钥材料需要重复使用，不得明文存储（可明文保存在TEE环境），建议加密后保存；

3. 密钥上报需要通过安全传输通道，在使用安全传输通道的情况下（例如，HTTPS），可明文传输密钥；

4. 服务端拿到客户端上报的密钥后，可对客户端上传的敏感数据密文进行解密，对应客户端密钥需要加密保护；

5. 客户端上传的敏感数据如果需要持久化存储，不得将敏感数据明文或者直接将客户端加密的密文存于数据库，需要使用服务端重新生成的密钥或已有的非客户端密钥对敏感数据加密后保存，确保密钥泄露影响最小化。

方案特点

1. 本方案基于客户端密钥上报机制实施，适用于前后端共享密钥场景；

2. 适用于有网络交互相关业务场景，对于没有网络的应用不适用；

3. 由于是客户端生成上报密钥，密钥材料具有一机一密，不同应用密钥互不相同特征。

  一方有难八方支援-基于服务端密钥下发方案  

   

方案说明

1. 上述方案首先需要客户端发出请求触发服务端密钥下发，可能场景有新增密钥、更新密钥等；

2. 服务端推荐每次请求使用安全随机数生成待下发密钥（这样可以做到一机一密），或者使用系统先前已经生成的密钥下发给所有客户端（效果是一密多机，密钥可能无法由客户端触发更新）。两种方式的密钥都需要加密保护；

3. 密钥下发需要通过安全传输通道，在使用安全传输通道的情况下（例如，HTTPS），可明文传输密钥；

4. 客户端拿到密钥可以对敏感数据加密，加密后的数据密文服务端可使用留存的对应密钥进行解密；

5. 客户端上传的敏感数据如果服务端需要持久化存储，不得将敏感数据明文或者直接将客户端加密的密文存于数据库，需要使用服务端重新生成的密钥或已有的非客户端密钥对敏感数据加密后保存，确保密钥泄露影响最小化；

6. 如果客户端需要对密钥持久化，不得明文存储（可明文保存在TEE环境）。

方案特点

1. 本方案基于服务端密钥下发机制实施，适用于前后端共享密钥场景；

2. 适用于有网络交互相关业务场景，对于不需要网络的业务不适用；

3. 可实现一机一密和一密多机（不推荐，密钥泄露影响范围广）两种效果，其中一密多机可适用于不同客户端或应用共享密钥场景。

▼

客套说辞

水货和干货都卖了一波，有赞的捧个赞场，没赞的捧个人场。南来的北往的，走过路过，千万别错过，小手一抖，转手就有。本人才疏学浅，到此为止了，还望大神飘过多多留足指点指点！

更多精彩阅读

END

长按关注  最新动态

---

好文！在看吗？点一下鸭！