银行加密体系与加解密算法速览

Posted 2023-04-04 迷途的小兵

一、银行3级加密体系说明：

转：加密体系介绍（LMK、ZMK、ZAK、ZPK）_炎升的博客-CSDN博客_lmk密钥

二、加解密算法

1、分类说明

其中按国际和国内使用主要分为：通用算法和国密。

通用算法可以参考：OpenSSL 中文手册 | OpenSSL 中文网

国密算法可以参考：国密算法简单介绍

按加密用途：有对称加密算法、非对称加密算法、摘要算法

文章可以参考：常见的加密算法、原理、优缺点、用途

2、标准说明

加密算法中涉及到很多标准，里面定义了如填充方式、编码方式、加密方式等的规范。

参考文章：密码学浅谈（2）：密码学标准 - X.509 与 PKCS 系列 - 知乎

ASN.1

ASN.1（Abstract Syntax Notation One) 是 ISO 和 ITU-T 的联合标准，是描述数据的表示、编码、传输、解码的灵活的记法。它提供了一套正式、无歧义和精确的规则以描述独立于特定计算机硬件的对象结构。

X.509

X.509 是密码学里公钥证书的格式标准。X.509 证书已应用在包括 TLS/SSL 在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）。

PKCS 系列

公钥加密标准（Public Key Cryptography Standards, PKCS），此一标准的设计与发布皆由 RSA 资讯安全公司（英语：RSA Security）所制定。

DER

X.690 是一种 ITU-T 标准，指定了几种 ASN.1 编码格式：

• 基本编码规则（BER，Basic Encoding Rules）
• 规范编码规则（CER，Canonical Encoding Rules）
• 可分辨编码规则（DER，Distinguished Encoding Rules）

BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则。这些规则在 ASN.1 用语中统称为传输语法，指定用于编码数据的确切八位字节（8 位字节）。

DER 是 BER 的子集，提供了一种对 ASN.1 值进行编码的方式。DER 适用于需要唯一编码的情况，例如在密码学中，并确保需要数字签名的数据结构产生唯一的序列化表示。DER 可以被认为是 BER 的规范形式。

PEM

互联网上使用的几个安全相关标准定义了 ASN.1 数据格式，这些格式通常使用基本编码规则（BER）或可分辨编码规则（DER）进行编码，这是二进制的编码。二进制数据格式的一个缺点是不能在文本传输（如电子邮件或文本文档）中交换。基于文本的编码的一个优点是，它们很容易使用通用文本编辑器进行修改；例如，用户可以连接多个证书以形成具有复制和粘贴操作的证书链。

3、分组加密

一般加密的过程都需要考虑：密钥长度、明文长度和密文长度问题。明文长度需要小于密钥长度，而密文长度则等于密钥长度。因此当加密内容长度大于密钥长度时，大部分加密算法都会进行分段加密。 

常见的分段模式有：ECB（Electronic CodeBook mode，电子密码本模式）、CBC（Cipher Block Chaining mode，密文分组链接模式）、CFB（Cipher FeedBack mode，密文反馈模式）、OFB（Output FeedBack mode，输出反馈模式）、CTR（CounTeR mode，计数器模式）

 参考文章：分组加密算法的几种工作模式 - 十一度 - 博客园

4、填充模式

大部分分组加密算法，对于长度比较长的数据，都会将数据分段成一个个的块Block再进行加密。每个块的长度都是等长的。遇到无法切割成等长的块的数据，就需要对数据进行Padding。

常见的padding算法有：

• ISO10126Padding
• OAEPPadding / OAEPWithAndPadding
• PKCS1Padding / **PKCS5Padding **
• SSL3Padding

参考文章：

分组加密中的填充介绍（PKCS1Padding / PKCS5Padding/ISO10126Padding）_pan_mlpan的博客-CSDN博客_pkcs5padding填充方式

 

三、Java使用过程的各种问题

1、Cannot find any provider supporting AES/ECB/PKCS7Padding

出现这个问题的原因是：java自带的是PKCS5Padding填充，不支持PKCS7Padding填充。
解决办法是：通过BouncyCastle组件来让java里面支持PKCS7Padding填充。在加解密之前加上：Security.addProvider(new BouncyCastleProvider())，并给Cipher.getInstance方法传入参数”BC”来指定Java使用这个库里的加/解密算法。

2、algid parse error, not a sequence

出现这个问题的原因是：公钥格式不对。之前遇到从加密机导出的公钥格式，跟用PublicKey.getEncode()获取到的内容不一致。加密机导出的内容少了，秘钥算法中的OID部分。

参考文章：SNMP ASN.1 OID编码规则_沙海石的博客-CSDN博客_asn.1 oid

一个加密通信过程

公钥密码体制(public-key cryptography)

公钥密码体制分为三个部分，公钥，私钥，加密解密算法。

加密：通过加密算法和公钥对内容（也称明文）进行加密，得到密文。加密过程要用到公钥。

解密：通过解密算法和公钥对密文进行解密，得到明文。解密过程需要用到私钥

由公钥加密的内容，只能由私钥解密；由私钥加密的内容，只能由公钥解密。

对称加密算法（symmetric key algorithms）

解密与加密使用密钥是相同的

非对称加密算法（asymmetric key algorithms）

加密使用的密钥和解密使用的密钥是不相同的。

RSA

RSA密码体制是一种公钥密码体制的一种算法

签名

签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过。一般是对传输明文做一个hash计算得到一个hash值（此过程不可逆），将hash值增加到明文后，统一加密后进行传送。对方收到后进行解密，hash校验，确保信息不被恶意修改。

一个加密通信过程

• 第一回合

“客户”--->"服务器"：你好

“服务器”--->“客户”：你好，我是服务器

//此最原始的非加密方式进行通信，服务器很容易就被hacker冒充，从而截获信息

• 第二回合（解决服务端被冒充的漏洞）

“客户”--->“服务器”：你好   //客户有一个服务器发布的公钥

"服务器"--->“客户”：你好，我是服务器   

“客户”---->“服务器”：向我证明你是服务器  //防止服务器被hacker冒充

"服务器"---->“客户”：你好，我是服务器{你好，我是服务器}[私钥|RSA]

“客户”---->“服务器”:{我的账号是aaa，密码是123，我银行卡的余额是多少}[公钥|RSA]

“服务器”---->"客户"：{你的余额是100元}[私钥|RSA]

//此处服务器用发来一段明文和私钥加密的明文，客户端用公钥解密，后对比明文，如一致，则说明此对端确实拥有对应的私钥，确实是可信服务器

//第二回合的漏洞在于：公钥是不同客户都会拥有的，故导致服务器发送给某一个客户的密文（其余额），能够被拥有公钥的所有客户解密，从而导致信息泄漏

• 第三回合（解决服务端到某个客户的通信，对所有客户可见漏铜）

“客户”--->“服务器”：你好   //客户有一个服务器发布的公钥

"服务器"--->“客户”：你好，我是服务器   

“客户”---->“服务器”：向我证明你是服务器  //防止服务器被hacker冒充

"服务器"---->“客户”：你好，我是服务器{你好，我是服务器}[私钥|RSA]

“客户”--->“服务器”：{我们后面通信用对称加密来进行，这是对称加密算法和密钥}[公钥|RSA]

“服务器”-->"客户"：{ok， 收到}[密钥|对称加密算法]

“客户”---->“服务器”:{我的账号是aaa，密码是123，我银行卡的余额是多少}[密钥|对称加密算法]

“服务器”---->"客户"：{你的余额是100元}[密钥|对称加密算法]

//上述过程都是基于客户能够安全获得服务器发布的公钥。

//获取公钥无外乎两种方式：1、把公钥放到互联网的某个地方的一个下载地址，事先给“客户”去下载；2、每次和“客户”开始通信时，“服务器”把公钥发给“客户”

但是这两种方法都存在弊端：对于1方法，客户根本没有办法确认这个下载地址是不是服务器发布的，下载的公钥不可信；对于2方法，任何荣都可以生成公钥、私钥对，无法确认公钥到底是服务器还是hacker的。

这些问题的根源都来自于客户端无法确认公钥与服务器的对应关系，不知道公钥是来自真正的服务器还是hacker。

为了解决此问题，从而产生的数字证书，数字证书可以保证数字证书里公钥确实是这个证书的所有者（subject）的，或者证书可以用来确认对方的身份。

• 第四回合（解决最初的公钥传递到客户的问题）

“客户”--->“服务器”：你好  

"服务器"--->“客户”：你好，我是服务器  ，这是我的数字证书（客户收到数字证书后，验证客服务端是否可行）

“客户”---->“服务器”：向我证明你是服务器，这是一个随机字符串 

"服务器"---->“客户”：你好，我是服务器{一个随机字符串hash后密文}[私钥|RSA]//客户收到对应的响应，解密后与随机字符串的hash结果进行比较。此处将随机字符串hash后加密，可以防止破解密钥

“客户”--->“服务器”：{我们后面通信用对称加密来进行，这是对称加密算法和密钥}[公钥|RSA]

“服务器”-->"客户"：{ok， 收到}[密钥|对称加密算法]

“客户”---->“服务器”:{我的账号是aaa，密码是123，我银行卡的余额是多少}[密钥|对称加密算法]

“服务器”---->"客户"：{你的余额是100元}[密钥|对称加密算法]

//通过四个回合的改进：通信过程还有以下几个问题：

1、检查证书完毕后，客户发送一个随机的字符串给服务器，确认其是否有对应的密钥，这导致客户可以用一个简单有规律的字符串，去给服务端加密获得密文，这样可以分析私钥的规律，从而可能导致私钥泄露

解决：服务器收到随机字符串后，对其hash后进行加密传输到客户，客户解密后与原随机字符串hash结果比较。

2、在双方通信的过程中，黑客可以截获发送了的加密内容，虽然无法破解此内容，但他可以扰乱通信过程。

解决：这个是给通信内容的包进行编号，从而确保每个包都含有一个序号或一个随机值，对端会丢掉之前出现过的信息，

3、hacker可以篡改截获后的密文，从而破坏服务器和客户之间的正常通信

解决：在信息后加一个数字签名，对端收到后，对其内容进行完整性校验