Java非对称加密开发(一)-基础与理论

非对称加密

非对称加密算法(asymmetric cryptographic algorithm)又名“公开密钥加密算法”,非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

最常用的非对称加密算法:RSA。

非对称加密的主要特点:

  1. 数据加密:公钥加密,需要对应的私钥解密。保证私密性
  2. 数据签名:私钥加密,需要对应的公钥验签。保证完整性和不被篡改
  3. 相对于对称加密,安全性加高,速度较慢。

一般主要应用场景为双向通讯加密和签名,双方如果采用非对称加密传输数据,则必须先交换公钥,正因为要保证交换公钥的安全可靠,所以才会后后面的证书,keystore等相关东西需要了解。

Keystore

什么是keystore

keystore貌似一个装秘钥的容器,里面可以装一组组的秘钥。我们可以从keystore中导出对应的秘钥(证书,私钥等),我理解它存在意义主要是便于管理非对称秘钥对,同时便于私钥的传递(虽然说有秘钥不落地的说法,但很多场景中还是需要传递和发放的。)

另外一种比较容易理解的说法,keystore是一个证书库(其实证书我理解也是秘钥),所有的数字证书是以一条一条(采用别名区别)的形式存入证书库的中,证书库中的一条证书包含该条证书的私钥,公钥和对应的数字证书的信息。证书库中的一条证书可以导出数字证书文件,数字证书文件只包括主体信息和对应的公钥,它可以用一个密码作为证书库的保护钥匙.

在Java体系中,keystore文件一般由keytool工具创建,同时Java安全API中也有对应的Keystore.class专门对keystore做了抽象和封装,Javadoc说明如下:

This class represents a storage facility for cryptographic keys and certificates. A KeyStore manages different types of entries. Each type of entry implements the KeyStore.Entry interface. Three basic KeyStore.Entry implementations are provided:

KeyStore.PrivateKeyEntry 1个加密的非对称私钥,并附带一个对应的的公钥的证书链 This type of entry holds a cryptographic PrivateKey, which is optionally stored in a protected format to prevent unauthorized access. It is also accompanied by a certificate chain for the corresponding public key.

Private keys and certificate chains are used by a given entity for self-authentication. Applications for this authentication include software distribution organizations which sign JAR files as part of releasing and/or licensing software.

KeyStore.SecretKeyEntry 存放一个加密的对称加密的密钥 This type of entry holds a cryptographic SecretKey, which is optionally stored in a protected format to prevent unauthorized access.

KeyStore.TrustedCertificateEntry 存放受信任的证书 This type of entry contains a single public key Certificate belonging to another party. It is called a trusted certificate because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject (owner) of the certificate.

keystore的分类

keystore常见的类型主要是java体系的秘钥库JKS,可以通过keytool生成的后缀为jks文件,另外一种常见的是openssl生成的PKCS12格式的fpx文件,网上导出可以找到他们互转的文档说明。搜索下资料整理下,除了以上2中外还有: JCEKS,BKS,UBER等

  • JKS和JCEKS是Java密钥库(KeyStore)的两种比较常见类型,JKS的Provider是SUN,在每个版本的JDK中都有,JCEKS的Provider是SUNJCE,1.4后我们都能够直接使用它。JCEKS在安全级别上要比JKS强,使用的Provider是JCEKS(推荐),尤其在保护KeyStore中的私钥上(使用TripleDes),但目前常用的还是JKS,可能是先入为主的原因。

  • PKCS#12是公钥加密标准,12是该标准的12个发行版本,在非对称加密应用较多,它规定了可包含所有私钥、公钥和证书。其以二进制格式存储,也称为 PFX 文件,在windows中可以直接导入到密钥区,注意,PKCS#12的密钥库保护密码同时也用于保护Key。

  • BKS 来自BouncyCastle Provider,它使用的也是TripleDES来保护密钥库中的Key,它能够防止证书库被不小心修改(Keystore的keyentry改掉1个 bit都会产生错误),BKS能够跟JKS互操作,读者可以用Keytool去TryTry。

  • UBER比较特别,当密码是通过命令行提供的时候,它只能跟keytool交互。整个keystore是通过PBE/SHA1/Twofish加密,因此keystore能够防止被误改、察看以及校验。以前,Sun JDK(提供者为SUN)允许你在不提供密码的情况下直接加载一个Keystore,类似cacerts,UBER不允许这种情况。

证书

什么是证书

网上到处是数字证书的说明,如果没有实践经验,看到抽象的理论文字,头不较大,摸不着关键。上次与同事交流的时候,问道给我们的商户发放证书,用于通讯签名和加密话题,有同学问究竟说明是数字证书,我想了下,用了一种比较通俗的方式简单介绍下,同学说动了,先整理下来。

在说证书前,我们先说下非对称加密的基础逻辑。 场景:A,B双方需要通讯采用非对称加密传输数据,A和B各个有一对非对称秘钥a和b。A发送信息给B时,需要使用B的公钥(b_public)加密数据,那么B就需要先把b_public交给A,在互联网时代,这个交给A的动作是比较丰富的,一般不是是找个优盘拷贝下来,打给飞的送过去,通常都是通过网络先传给A。

问题:A怎么能相信这个b_public真的是B发过来的呢?或者中间是否被替换了呢?!存在这些风险和安全问题?

解决:怎么解决?于是出现了第三方权利机构CA.

  1. CA说请都相信我(我有权利,我是上帝~),B把b_public交给CA.
  2. CA的私钥对b_public签名,然后把B的实体信息,b_public及签名组合在一起,叫证书b_cert给A.
  3. A使用CA对全球公布的公钥验证b_cert证书里面的b_public是否正确,验证通过,则A可以使用这个证书里面的公钥进行加密数据发送给B了。

OK,则个就是我给同学讲的场景,这个场景说明证书是第三方信任机构颁布的证明公钥及所有者信息合法有效的证明文件。当然广义证书里面也可以有私钥和其他信息的。

下面是抽象理论说法,什么是证书呢? **证书是实体及公钥的数字签名。**多精简~~

  • 实体: 一个实体可以是一个人,一个组织,一个程序,一台计算机,一个商业,一个银行,或其他你想信任的东西.
  • 签名 :用实体私有钥匙加密某些消息,从而得到加密数据;
  • 公共钥匙 :是一个详细的实体的数字关联,并有意让所有想同这个实体发生信任关系的其他实体知道.公共钥匙用来检验签名;
  • 私有钥匙 :是一些数字,私有和公共钥匙存在所有用公共钥匙加密的系统的钥匙对中.公共钥匙用来加密数据,私有钥匙用来计算签名.公钥加密的消息只能用私钥解密,私钥签名的消息只能用公钥检验签名。

公私钥关系:他们是成对关系,(加解密)公钥加密 -> 私钥解密; (签名验签)私钥数字签名 -> 公钥验证。

证书的分类

带有私钥的证书 1、由Public Key Cryptography Standards #12,PKCS#12标准定义,包含了公钥和私钥的二进制格式的证书形式,以pfx作为证书文件后缀名,其实就是keystore,我们也可以把Java体系的jks文件作为证书(关键是自签还是CA签名认证)。

不带私钥的证书 包括二进制编码和BASE64编码证书,BASE64一般便于查看。一般以cer或crt作为扩展名。证书中没有私钥,只是公钥,实体信息和签名,这是标准意义上的证书。

密码编码

密钥有多种形式的,很多情况下,需要把这些密钥保存下来。通常使用PEM和DER两种编码方式对要保存的密钥进行编码。

DER编码存储的密钥文件是不可读的,如果用文本编辑器打开它,将看到一些难以理解的符号,因为这是一个二进制编码的文件。PEM则不一样,它要友好得多,因为PEM经过BASE64编码。用文本编辑器打开PEM编码的密钥文件,可以看到跟证书类似,它们真正的编码都包含在类似于:—BEGIN XXXXXX—和—END XXXXXX— 这样的符号对内。

我们常见的pem扩展名文件就是PEM密码编码,一般都用于保存公私钥文件.全称为:Privacy Enhanced Mail,是一种保密邮件的编码标准。通常来说,对信息的编码过程基本如下:

  1. 信息转换为ASCII码或其他编码方式,比如采用DER编码。

  2. 使用对称加密算法加密经过编码的信息。

  3. 使用BASE64对加密码后的信息进行编码。

  4. 使用一些头定义对信息进行封装,主要包含了进行正确解码需要的信息,头定义的格式形式如下:

    Proc-Type:4,ENCRYPTED DEK-Info:cipher-name,ivec 其中,第一个头信息标注了该文件是否进行了加密,该头信息可能的值包括ENCRYPTED(信息已经加密和签名),MIC-ONLY(信息经过数据签名但没有加密),MIC-CLEAR(信息经过数字签名但是没有加密,也没有进行编码,可使用非PEM格式阅读),以及CLEAR;第二个头信息标注了加密的算法及对称加密块算法使用的初始向量。

  5. 在这些信息的前面加上如下形式头标注信息:—BEGIN PRIVACY-ENHANCED MESSAGE— ,在这些信息的后面加上如下形尾标注信息: —END PRIVACY-ENHANCED MESSAGE— 。

总结

  • Keystore用于是秘钥库,用来安全存储和管理秘钥(公钥和私钥)。常见2种jks和pfx为扩展名的文件格式,可以互转。
  • 秘钥(公钥和私钥)一般都是用PEM方式保存。扩展名一般为pem。PEM和DER是编码格式,证书既可以用DER(二进制格式)保存,也可以用PEM(基于Base64的字符格式)保存。
  • 发布公钥为证书,需要生成证书签名请求文件,一般叫CSR文件,也是扩展名,提交个CA。
  • CA用自己的私钥文件签名之后生成的CRT文件就是完整的证书了,CER和CRT其实是一样的,只是一般Linux下面叫CRT多,Windows下面叫CER多。
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

zp820705

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值