在本地加密存储的方法，加密方法有两种：对称加解密和非对称加解密。实用场景：支付系统中有部分配置文件的内容需要加密存储在本地，例如：跳转服务器的地址或支付SDK的运行参数在使用过程中需要先解密再使用。对于这种场景，比较适合采用对称加密算法，如图1所示。
图1
当然，也可以使用非对称加密，如图2所示。但由于非对称加密适用于安全级别较高、运算速度较慢及私钥一般不在终端存储等场景中，所以在技术选型上面不宜使用。
图2
说到对称加密算法，可以选择使用以下几种方案。
这里的终端安全示例代码以Android操作系统为例，并且使用Java来实现安全加密、访问授权和传输安全。
1、中低安全级别的数据（DES）
（1）数据加密标准DES（Data Encryption Standard）是使用对称密钥加密的一种块加密算法，处理数据的速度较快，性能较好，通常适用于对大块数据加解密的场景中。该算法的明显缺点是密钥较短，这意味着可以通过暴力破解来解密，降低了加密的安全性，但仍然适用于对支付系统配置文件的安全加密等场景中。
以下是基于Android系统的DES加密的代码实现：
对应的解密函数如下：
这样就实现了加解密函数，只需在加密时调用encryptByDES函数，将明文数据和8位Key传入就可以得到密文数据，然后在使用时以相同的Key值和密文调用decryptByDES函数完成密文解密得到明文信息。
在以上代码中还使用了Base64编码方式，可以将二进制数据编码成可见的ASCII码字符串数据。在Android系统中Base64（完整类名为android.util.Base64）已经是一种内置的工具类的编码转换算法，很多人都把Base64当成一个加解密算法，但从严格意义上来说，它不能算是一种加解密算法，只能算是一种编码格式的转换算法。
2、DES算法演进之3DES
在DES基础之上进化了三重数据加密算法（3DES），该算法使了K1、K2、K3对同一组明文进行多重加密，其基本原理是对每个数据块都使用三次DES加密，如果密钥小于64位，则其加密强度与DES一致，一般建议采用的密钥超过64位。
3DES的加密函数示例如下：
其中涉及的加密编码方式和填充方式包括3DES-ECB、3DES-CBC、3DES-CTR、3DES-OFB和3DES-CFB。
解密函数示例如下：
其中三重数据加密算法的密钥长度是128位。除了3DES算法还有人演算出N-DES（N重数据加密算法）。
3、高安全级别的数据（AES）
由于密钥长度过短、弱密钥等缺点的存在，DES容易被暴力破解。
随着计算机性能不断提升，DES被暴力破解的频率越来越高。所以，美国国家标准与技术研究院（NIST）在1997年放弃了对DES的官方支持，研发出DES的替代者AES（Advanced Encryption Standard，高级加密标准）。
在Android系统上使用AES与使用DES的实现难度、代码量和写法相差无几，比DES速度更快、性能更高，在实际的开发过程中建议采用AES算法对数据进行加解密，其加密代码如下：
解密代码如下：
针对对称加解密算法都有一个密钥需要存储的问题，目前有三种实现方案。
（1）生成密钥之后，可以将其保存在存储设备中，例如密钥文件或Android系统的SharedPreferences中，在使用时将其读取到内存中。
（2）生成密钥之后，依据固定的设备特性（例如Deviceld、OSID等）将密钥信息上送到服务器端，在应用启动时将密钥信息获取到本地使用，由于移动网络通信存在不确定性，所以不推荐采用这种方案。
（3）将密钥放在NDK代码中，然后采用数据位移或拆分等方案，再拼装为真正的密钥数据。这种算法的破解难度较高，也较安全，推荐采用这种存储方案。
4、非对称加密（RSA）
RSA是一种非对称加密算法，由三位数学家Rivest、Shamir和Adleman设计，其核心思想为将密钥分成以下两把密钥，简称密钥对。
在密钥对中有一个公钥，还有一个私钥。
·公钥（Public Key）：是密钥对中完全公开的部分，任何人都可以得到它，适用于客户端服务端模型。
·私钥（Private Key）：是密钥对中保密的一部分，一般在服务端安全存储，不允许在客户端存储。
可以使用OpenSSL工具的命令生成公私钥，也可以使用开发语言生成公私钥。
（1）生成RSA算法的私钥时，使用以下命令：
（2）使用以下命令将X509编码文件转换成PKCS8编码格式：
（3）导出私钥对应的X509编码公钥文件：
注意：可以使用Java代码从rsa_ private_ key_ pkcs8.pem文件中读取私钥信息并生成数字签名，再使用rsa_publicg_ key.pem公钥文件验证数字签名的正确性。
Java虚拟机也提供了内置的方法来生成公私钥，代码如下：
有了公私钥数据之后，就可以对数据进行加解密处理和数据加签、验签了，加解密过程如图3所示。
图3
（1）加密数据的一方使用公开获得的公钥（一般推荐使用1024位密钥，密钥越长越安全，也意味着加密性能越差），对明文数据进行加密得到密文：
（2）解密的一方具有私钥，拿到密文时，使用对应的私钥进行解密：
（3）如果解密失败，则代表公钥或私钥不匹配（不是一个密钥对），这也说明如果没有对应的私钥，则解不出密文中的内容。
RSA一般只适用于小数据块的加解密场景中（例如加密动态密钥、短的关键数据），加解密速度较AES和DES慢。
5、传输安全
数据的传输安全需要满足以下条件。
·防窥探：数据明文受到保护，不应该被黑客和恶意用户识别、利用。保护数据不被窥探是一项重 要的指标，发送者和接收者双方都需要实现加密技术，保证数据无法被第三方破解和解密。
·防篡改：保护数据在传输过程中的完整性，必须确认不会在数据传输过程中被截获和篡改。
·防伪造：能识别数据发送方是否具有合法性，并且能确认发送方的真实性。
下面讲解相应的技术实现方案。
1.防窥探
数据一般通过计算机网络进行传输，除了有从一个发送方（发送节点）发送到接收方（接收节点）的简单场景，还有复杂的场景（经过N个网络节点传输才能到达最终目的地）。随着节点的增多，在这个传输过程中被截获、监听的风险越来越高（例如：现在常用的网络数据抓包软件就有Fiddler、Wireshark等，可以监听到网络层都采用了什么协议、调用了哪些API，以及发送参数、返回的响应数据分别是什么）。
在客户端一般采用公开的通道加密方案保证通道数据无法被窥探。
TLS（Transport Layer Security）又叫作安全传输层协议，主要用于在两个通信应用程序之间提供保密性和数据完整性。
Android系统对应的实现如下。
首先，读取自己的证书并初始化TLS的工厂类：
然后，获取SocketIJ类，创建Socket连接，开始TLS握手：
2.防篡改
在某支付场景中，客户端与服务端的请求被黑客截获并将支付订单的金额修改为0.1元（原订单金额10元），由于未在这个过程中对订单数据进行防篡改校验，导致了商户的商品被便宜卖掉，造成了商户的经济损失。
数据防篡改的主要手段是针对数据进行客户端加签，在服务端接收数据时验证加签数据是否与签名一致。加签的过程实质上是发送端针对待发送的原始数据进行一定的处理（例如字符串去空格、字段排序、数据加密）后针对数据加签生成签名摘要数据，这部分摘要数据一般不会参与加密。接收端在收到数据之后，先将签名摘要数据和加密数据取出来，然后解密已加密的数据块得到原始数据，最后像发送端一样进行处理，生成签名摘要数据。 如果生成的摘要数据与发送端传送过来的一致，则表示数据没被篡改过，否则表示数据在传输过程中被篡改。
下面讲解对防篡改的数据进行签名和验签的过程。
（1）对原始数据去空格，进行参数字段排序（升序或降序）和拼接。
（2）将原始数据（待签名内容）根据参数字段名称进行排序，可以保证加签、验签的双方待验证参数内容的一致性。例如：排序升序规则按照第一个字符的ASCII码值递增排序，如果遇到相同的字符，则依据第2个字符排递增序，以此类推。将排序后的参数拼接成“参数=参数值”的格式，并且把这些参数使用‘“&”字符连接起来。
（3）生成摘要数据，常用的摘要算法有MD5、SHA-1等。 下面使用MD5生成摘要数据：
（4）使用非对称加密算法RSA，利用客户端的公钥对摘要值进行加密，将数据通过网络发送给接收方进行验证。
接收方在接收到数据之后进行验签，与加签的过程基本一致。
（1）参数排序。将收到的参数内容（key=value字典）根据参数名称进行排序，其排序规则与签名方保持一致，对参数字符串去空格和拼接，其拼接方式与签名方保持一致，生成待生成摘要的原参数字符串。
（2）生成摘要数据。使用相同的摘要算法（MD5）计算得到验签方的摘要值。
（3）进行非对称解密。使用RSA非对称加密算法，对收到的加密摘要数据使用私钥进行解密，并得到签名方的原始摘要值。
（4）摘要数据对比。如果签名方的摘要数值等于验签方计算出来的摘要值，则表示验签成功，否则验签失败。
