标签：rsa u盾 非对称加密
概述
首先了解一下相关概念：RSA算法：1977年由Ron Rivest、Adi Shamirh和LenAdleman发明的，RSA就是取自他们三个人的名字。算法基于一个数论：将两个大素数相乘非常容易，但要对这个乘积的结果进行 因式分解却非常困难，因此可以把乘积公开作为公钥，该算法能够抵抗目前已知的所有密码攻击。RSA算法是一种非对称算法，算法需要一对密钥，使用其中一个 加密，需要使用另外一个才能解密。我们在进行RSA加密通讯时，就把公钥放在客户端，私钥留在服务器。
RSA非对称加密算法，可以验证客户端和服务器双方的合法性，安全级别非常高！
iOS平台RSA介绍
我们常见的证书可以看做是公钥，证书中包含了公钥和一些其他信息。IOS客户端的加解密，首先我们需要导入Security.framework，在iOS中，我们主要关注四个函数。
SecKeyEncrypt：使用公钥对数据进行加密。
SecKeyDecrypt：使用私钥对数据进行解密。
SecKeyRawVerify：使用公钥对数字签名和数据进行验证，以确认该数据的来源合法性。
SecKeyRawSign：使用私钥对数据进行摘要并生成数字签名。
从这几个函数中，我们可以看到，公钥能做的事情就有两个：加密数据，以及对服务器端发来的数据进行签名认证，但是如果你想跟我之前想的一 样，要使用公钥来对数据进行解密，那就没有自带API了。如果想在服务器端使用私钥加密数据，然后再在客户端使用公钥进行解密，以图这样来对交互数据进行加密，看来是行不通的。其实也应该是这样，公钥是公开的。同时，RSA因为都是做大数的运算，算法性能上比较差，如果做大数据量的加解密，对IOS来讲，肯定也是不合适的。
案例
以我们项目为例，把序列图画出来，对应看一下
前提条件客户端和Server商量好，生成一对儿公钥-私钥，客户端写死到代码中，称之为buildin-key
1. 客户端发送cNonce给Server，Server用私钥对（cNonce+public-key+sNonce）进行数字签名生成signature。Server把sNonce、public-key和signature应答给客户端
2. 客户端对Server的应答进行验证。验证过程是：buildin-key调用SecKeyRawSign函数对（cNonce+public-key+sNonce）进行验证。
3. 客户端使用public-key（动态公钥，因为这样更安全）对密码摘要、sNonce进行加密。
4. Server收到后，解密数据得到密码摘要，匹配密码摘要和sNonce是否正确。
其中，第二步是客户端对Server进行验证，第四步是Server验证客户端。
银行U盾
U盾是一个自带存储计算功能的微型电子板，上面应该有加密存储部件，用于写入证书，但此存储部件无法通过外界USB接口读取，但MPU可读取并解密（细节不清楚），此功能通过物理线路来实现，如果通过硬件解剖，应该可以读取加密后的内容，但还是无法解密。还应该有微型处理器，MPU，用来运行加密算法和响应外界USB接口指令，此为核心部件。
U盾的工作过程：当网银响应用户操作，将所有的指令信息打包，并通过USB口送入U盾，U盾在其内部由MPU使用证书（私钥）进行签名，然后送出。再由IE通过SSL传送到服务器。服务器收到指令包后由用户留存在密钥分发服务器上的公钥进行签名认证，若认证无误则执行指令。
理论上来说，在通过两个大素数生成一对公、私钥对后，银行密钥分发管理系统应该将私钥发给用户，并写入U盾，然后将服务器上的这两个大素数和私钥删除，只留存公钥。然而，实际工程过程中，有很多安全隐患：
隐患一
将私钥发给用户的过程中，有可能被第三方截取，虽然此过程使用了SSL通道，并凭银行的密码下载。但如此此用户的电脑被人控制，IE被篡改，还是有被盗取的可能性。不过下载证书是一次性动作，两年才一次。
隐患二
由于大素数的寻找十分困难，所以在工程实现中不可能做到一次一密：也就是通过同一对大素数会生成很多公、私钥对，而且这一对大素数会在服务器上留存。一方面，多个共模的公、私钥对之间可能存在相关性；另一方面，如果有人接触到了服务器上留存的大素数，很容易就通过用户的公钥来恢复出私钥。 个人猜测，银行应该是通过一个大素数池，随机挑选两个进行生成密钥对。而且这个大素数池要定期更换，并且非常严格地监管此密钥分发服务器。
总结
破解RSA被认为是所有计算机科学中最难的课题之一。因此，如果你发明了一种能够快速地将一个极大的数字分解为质数的方法，就不仅仅能够入侵瑞士银行的账户系统，而且还可以获得图灵奖了！
浅谈IM软件业务知识——非对称加密，银行U盾的原理,布布扣,bubuko.com
浅谈IM软件业务知识——非对称加密，银行U盾的原理
标签：rsa u盾 非对称加密
原文地址：http://blog.csdn.net/hherima/article/details/31356575
