加密解密,数字签名及证书

对称加密

分类

  1. 数据加密标准DES(56位密钥长度,密钥太短,抗穷举能力差,安全性不够)
  2. 三重DES-DESede(112和168两种密钥长度,抗穷举能力显著增强, 但由于进行了多重des迭代,造成处理速度慢,效率不高)
  3. 高级数据加密标准AES(128和192及256三种密钥长度,搞穷举能力强,速度比des系列加密快,为替代des系列加密算法而生)

对称加密步骤

  1. 由消息传递双方约定密钥
  2. 消息发送方使用密钥对明文加密,并将密文发送给接收方
  3. 消息接收方使用密钥对密文解密获取明文

image

对称加密的问题

  1. 甲与乙通信,甲乙事先需要打电话或者发邮件或者面对面约定密钥key1
  2. 甲与丙通信,甲丙事先需要打电话或者发邮件或者面对面约定密钥key2
  3. 甲与丁通信,甲丁事先需要打电话或者发邮件或者面对面约定密钥key3

如果甲要与N方通信,就得事先打电话或者发邮件或者面对面与N方约定N个密钥,以浏览器为例,其会与数不清的网站通信,浏览器开发者不可能事先打电话或者发邮件或者面对面与各个网站开发者约定密钥。

所以问题来了,通信两方该如何事先约定密钥呢,显然打电话或者发邮件或者面对面这种人工约定密钥的方式是不可行的,这时需要非对称加密算法来解决这个问题了。

非对称加密

分类

非对称加密算法也比较多,典型常用的有dsa,rsa算法

特点

  1. 每个通信方都有一对密钥,公钥和私钥,公钥对外公开,私钥自己保存不对外公开
  2. 公钥加密的数据必须用其对应的私钥才能解密,私钥加密的数据必须用其对应的公钥才能解密

非对称加密的这些特点,即可解决上述人工交换对称加密算法密钥的问题,具体见下图

加密流程

image

以上就是对数据加密的介绍,可以看到,数据加密可以保证纵使数据被敌人窃取,也无法识别出具体内容,达到数据的保密性。但假如窃取者将这个无法识别的数据替掉,换成具有误导性错误的数据发送给数据接收方,那么数据接收方该如何识别收到的数据是否真实的,没有被窜改的呢?如下图这种情况

image

要解决上面问题,需要利用数据摘要和签名对数据进行完整性验证及身份识别

数据摘要

定义

固名思义,就是取数据的摘要,大纲,特征码

分类

主要有md系列和sha系列算法
1. md系列又分md2,md4,md5等,比较常用的就是md5,无论数据有多长,md算法都会生成一个128位的摘要,来表征这个数据。
2. sha系列也分很多种,sha-0,sha-1,sha-2,sha-256等等,常用的是sha-1算法,其会对数据生成一个160位的摘要,来表征这个数据。

摘要算法验证数据完整性流程

  1. 通信双方约定摘要算法
  2. 数据发送方获取数据的摘要m,将数据和其摘要m一起发给接收方
  3. 接收方取得获取的数据,并利用约定的摘要算法计算数据的摘要m2,与收到的摘要m比较,相等说明数据没有被更改

但上述验证其实是有bug的,见如下图
image

如何解决bug了,这时需要用到mac算法

MAC消息认证码算法

MAC是结合了摘要和对称加密算法的摘要算法(个人认为也是一种签名算法,后面会看不到其不仅可以验证完整性还可以认证数据源),可以认为就是相比前的摘要算法多了一步,就是对摘要结果进行一次加密后的数据作为最终结果。

分类

主要有HmacMD5, HMacSHA1, HMacSH256, HMacSHA384等等,与前面的摘要算法都是对应的

mac消息认证算法验证数据完整性流程

  1. 通信双方约定mac算法和密钥
  2. 数据发送方获取数据的认证码m,将数据和其认证码m一起发给接收方
  3. 接收方取得传来的数据,并利用约定的mac算法和密钥计算数据的认证码m2,与收到的认证码m比较,相等说明数据没有被更改

看上去与摘要验证流程相比没有差别,就多了一个密钥,但就是多的这个密钥,解决了前面摘要算法进行数据完整性验性的bug,具体见下图

image

另外从上图也可以看出,mac消息认证码不仅可以验证数据完整性,还可以认证数据发送方身份,因为mac所用的密钥只有通信双方才知道,截窃不知道这个key就无法生成正确的code,数据接收方就无法通过验证。当数据接收方一旦通过了验证,不仅说明数据是完整的,并且说明数据发送方没有被委造。

数字签名

什么是数字签名

数字签名可以认为是带密钥的数据摘要算法,并且这种密钥使用的是公钥和私钥,是数据摘要和非对称加密的结合体。类似手写签名,主要是用来验证数据完整性和认证数据来源。

其校验和认证流程分为以下几步:
1. 消息发送方公布自己的公钥
2. 消息发送方利用自己的私钥对数据签名得到签名值,并将数据和签名值一起发送给接收方
3. 接收方利用发送方的公钥对数据和签名值进行验签

image

image
可见与上述消息认证码校验流程非常相似,并且可以知道签名时是私钥加密,公钥解密,与之前加密数据(交换密钥)时相反,那里是公钥加密,私钥解密

签名算法分类

主要包括RSA,DSA和ECDSA共三种算法

数字证书

回顾前面浏览器与银行通过非对称加密算法进行交互通信密钥的流程图

image

要解决这个问题用到数字证书

数字证书是什么

数字证书类似我们的身份证,用于标识通信方的身份,其本身就是一个格式规范的文件,如下图所示

image

其中最重要的信息有签发机构,签发机构签名,证书的持有者名称,证书持有者的公钥

证书每个人都可以制作,但需要到权威机构作认证,否则没有可信性。

有了证书,就不用担心假冒银行网站了,仍以前面例子为例,浏览器向银行请求公钥,其实应该是请求银行的证书(证书里有公钥),假设浏览器请求被劫持到一个假冒银行,浏览器收到假冒银行自己的制作的证书,浏览器发现这个没有被权威机构认证,不可信,就会中断通信,所以没安全问题。再假如假冒银行拿到真招行的数字证书返回给浏览器(这个可以拿到,证书是公开的,想拿都可以拿),浏览器通过验证,发现证书是真的,就用证书上的真招行的公钥加密通过密钥key返回给假冒银行,这时也没有问题,因为这个key是用真招行的公钥加密的,需要用真招行的私钥来解密,而假银行没有招行的私钥,无法解密,他得不到真实的通信密钥key,这也是安全的,密钥没有泄露。

前面一直说浏览器可以判断一个证书是经过权威机构认证了的还是自己制作的不可靠的证书,这是如何做到的呢?见下图

image

浏览器已经内置了这些权威证书认证机构的公钥,所以可以利用这些公钥来判断证书是不是那个权威机构认证过的。

你可能感兴趣的:(加密解密,android开发)