对于移动应用的安全交互在金融类似的领域要求比较高；在一些对数据比较敏感的应用中也有类似的要求；
今天找时间就把我所知道的和大家分享下，本文算是科普文，想深入了解的同学请自行阅读相关书籍；
概要：
首先我们需要区分几个比较重要的概念：摘要、签名和加密；
之后我们介绍实现这些过程的方式-密码学基础；
1.哈希函数；
2.对称加密；
3.非对称加密；
最后我们介绍几个常用的加密算法：
哈希算法：md5、SHA-256；
对称加密算法：AES；
非对称加密算法：RES；
这些概念乍一听起来可能会觉得比较麻烦，难理解，但不用害怕，当你清楚了之后，你会发现他们其实很简单；
摘要、签名和加密：
为了说清楚这些概念我们先举一个具体的场景：
场景：
Elly和
Bob是好朋友，但他们相距很远，只能通过古老邮寄信件的方式进行联系；某一天
…
Elly给Bob写了一封信，新的内容是“我现在急需用钱，请借给我100￥，转到我的xxx账户里…”；
在遥远的Bob，收到了这封信，Bob作为朋友提供了帮助…
但，如果我是Bob，我会想：这封信是我的好朋友Elly发的吗？如果是其他人冒充的可就糟了呀…
的确，任何人都可以做这样的事情，那么我们如何才能避免其他人冒用Elly的名字，来向Bob请求帮助呢？
我们想到如果Elly对这封信签上自己的名字，Bob收到信之后，就可以查看签名是不是Elly的，这里有个前提就是 Bob很清楚Elly的字迹，别人很难模仿；
这样Bob就知道这封信的的确确是Elly发过来的；（因为其他人无法模仿Elly的签名）
这里，我们来引入我们要介绍的第一个概念：签名；
这里还有两个问题：
1）这封信的内容，是可以被其他人截获的，在信件邮寄的过程中，如何保证信的内容不被其他人获取？
2）信中的内容真实可信，没有被任何人篡改过吗？
我们看这两个问题，如果信件在传输过程中无法被其他人获取，自然就不存在被人篡改的可能；
但如果信件能被其他人获取，还能不能保证信件中的内容不被篡改呢？
其实是可以的：这个不难理解，因为信中的每个字都是Elly的字，和签名类似，Bob认识其中的每个字，也能把不是Elly写的字识别出来；
我们拓展下思维，如果信中内容很多很多，多到Elly自己写不完，只好借助打字机来完成，那我们上边说的方式貌似就不好用了( ⊙ o ⊙ )啊！
我们再想想办法：
我们用相机把所有的信息来个快照，这样就把大量的信件内容，和一张照片对应起来了，在照片的反面Elly签上名；附在信中就可以了；
当Bob收到信之后，就可以对比照片和信中文字内容，但这样做还是很麻烦，如果Bob也按照同样的方式对这些内容进行快照，然后比对Elly的快照和自己的快照是否不同，就能知道，新的内容是否被篡改了；
验证信件没有被篡改之后，在验证下Elly快照上的签名，就知道这的确是Elly发来的信件，信中的内容真实可信，且没有被篡改过；
通过上面的描述，我们引入另一个重要的概念：摘要（就是我们说的快照）；
到目前为止我们应该清晰了几个事情：
内容可以签名；（Elly写的字）
签名无法被冒用；（Elly写的自己的名字）
内容很多可以生成摘要； （Elly的快照）
摘要和内容是一一对应的；（Elly对内容的快照）
可以对摘要进行签名；（Elly签名之后的快照）
摘要是可以进行比对的；（Bob的快照和Elly的快照进行比对）
签名可以验证；（Bob知道Elly的字迹）
接下来我们看看之前剩下的一个问题：
如何保证信的内容不被其他人获取？
这就涉及到我们最后要介绍的一个概念：加密；
如果Elly对信中的内容进行了加密，Bob收到之后在进行解密，就能保证这个信的内容不被其他人获取到；
加密的方式有很多：比如我们可以将信中内容倒序，每个若干位字符兑换位置…. 总之最后看到的信的内容可能是一些不相关的文字
有了上边设定场景中介绍的概念，现在我们来看看密码学中能给我们什么样的帮助；
密码学基础：
1.哈希函数；
摘要的生成，我们可以通过哈希；
简单介绍下哈希：
哈希函数的三个特性：
1.
可输入任一大小的字符串；
2.
产出固定大小（
256
位），规模需要足够大；
3.
可以进行有效计算，即在合理时间内能够完成计算；
密码安全的哈希函数附加条件：
1.
碰撞阻力；
2.
隐秘性；
3.谜题友好；
碰撞阻力：
碰撞就是：不同输入，产生相同输出；
对于哈希函数H(·)，
如果没有人能够找到碰撞
，那我们就称该函数具有碰撞阻力；
鸽巢原理：
100个输出空间 我们选择101个输入 一定会有碰撞；
但是如果输出空间足够大（很大。。。）可能无法找到有效检测碰撞
的方法（世界上没有哈希函数能够具有防碰撞特性）；
我们现在依赖的加密的哈希函数仅仅是人们经过不懈努
力之后暂未找到碰撞的函数；
——
我们选择相信这些加密的哈希函数具有哈希阻力或碰撞阻力；
也因此，我们可以将哈希输出作为信息摘要；
隐秘性：
通过输出 无法猜出输入，即隐秘；
谜题友好：
简单讲就是，划定一定的输出范围（哈希结果的范围），找到对应的输入值（需要哈希的参数）的时间不会太小；
如果一个哈希函数具备谜题友好特性， 这就意味着对于这
个谜题没有一个解决
策略， 比只是随机地尝试
x
取值会更好；
是不是觉得熟悉，对 这就是比特币的“挖矿”；
2.对称加密：
3.非对称加密：
关于对称、非对称加密我们简单的概念挪用了过来，细节的部分大家可以借阅相关文章；
简单来说，对称加密就是同一个秘钥的加解密，对于非对称来讲，公钥和私钥的使用可能要复杂些：
公钥就是公开的秘钥，Elly可以生成一对秘钥对（任何人都可以生成自己的秘钥对），私钥自己保留，公钥就可以向所有人公开；
私钥和公钥可以加解密：
公钥加密的内容可以用私钥来解，反之亦然；这就涉及到一个问题，就是什么时候使用公钥加密，什么时候使用私钥加密？
我们可以这样区分：
公钥可以被所有人获得，私钥则只能能由生成秘钥的人保留，其他人无法获取；
那么使用私钥加密，就十分类似上述场景中Elly对快照（摘要）进行签名的过程，只有Elly才有的私钥 对应 Elly自己的签名，所以我们可以使用私钥对摘要（哈希值）进行签名；有公钥的人就可以通过解密的过程来验证签名；
这个私钥签名，公钥验签的过程，同Elly对摘要快照的签名过程一样，摘要保证了数据的完整性和不可被篡改，签名和验签的过程保证了内容确实是来自与Elly；
如果Bob想给Elly回信，信的内容不希望被其他人获取到，就可以使用Elly的公钥进行加密，这样只有持有相应私钥的Elly才可以解密，获取信的内容，这样就可以保证了数据的安全性和不可被获取；（如果Elly发给Bob的信也想保密传输，则可以使用Bob的公钥来对数据进行加密）
完整的场景过程图示：
值得注意的是，签名和加密并无区别，只不过签名使用的是私钥，加密使用的是公钥，本质上都是加密的过程；验签和解密本质上就都是解密的过程；
现在把Elly当成移动端，Bob作为服务端，重新理解一下上述过程，相信你会有所收获；
常用的加密算法：
哈希算法：md5、SHA-256；
对称加密算法：AES；
非对称加密算法：RES；
写到这里，相信大家都已经明白这三类算法的作用，概念大家自行查阅；这里说一下使用时需要注意的配置：
AES：
RSA公钥加密：
RSA私钥加密：
关于这些加密算法和参数的理解，大家可以参考《
移动端加解密总结》这篇文章，讲的很不错；
在两端进行加解密交互的时候，请确保这些设置都是一致的；ok 就这些，希望大家能有收获！如有错误，欢迎指正。
续：使用图形验证码防止短信攻击
1.获取平台公钥：
->platform_private_key
2.获取图形验证码：
->valid_code_key
->valid_code_img_data
3.获取短信验证码：
<-phone_number（使用平台公钥加密）
<-valid_code_input
<-valid_code_key
4.获取access_token(放重发 有效时间极短):
<-random_str
<-phone_number
->access_token
5.登录：
<-phone_number（使用平台公钥加密）
<-password（使用平台公钥加密）
<-access_token（防重发标识）
<-random_str（用于生成防重发标识的随机串）
<-valid_code_input（图形验证码验证 配合密码登录）
<-valid_code_key（图形验证码验证 配合密码登录）
<-sms_code_input（短信验证码登录/验证）
有效步骤中关键的一步是识别图形验证码；
续：有关数据加密过程的处理
1.防截获的方式是使用平台公钥加密；
2.防篡改的方式是使用用户私钥签名；
问题的关键在于如何获取平台公钥和用户私钥；
平台公钥是公开的，用户私钥可以使用aes加密，通过接口返回；
aes加密key由客户端随机生成不固定，经公钥加密作为接口参数；
由于aes加密偏移量的约定设置，其他人无法解密拿到私钥，保证私钥的私密性；