Autosar之自签名证书与CA证书

一、安全传输

1.框架

在这里插入图片描述

2.如何实现传输安全?

“加密 + 签名 + 证书”,本质上就是在非安全信道中实现数据安全传输的解决方案。

  • 1、加密 —— 防窃听 : 将明文转换为密文,只有期望的接收方有能力将密文解密为明文,即使密文被攻击者窃取也无法理解数据的内容;

  • 2、验证完整性 —— 防止篡改: 对原始数据计算摘要,并将数据和摘要一起交付给通信对方。接收方收到后也对数据计算摘要,并比较是否和接受的摘要一致,借此判断接收的数据是否被篡改。
    不过,因为收到的摘要也可能被篡改,所以需要使用更安全的手段:数字签名(对摘要的加密即数字签名);

  • 3、认证数据来源 —— 防止伪装: 数字签名能够验证数据完整性,同时也能认证数据来源,防止伪装。

3. 对称加密和非对称加密的区别?

  • 1、密钥管理: 对称加密算法中需要将密钥发送给通信对方,存在密钥泄漏风险;非对称加密公钥是公开的,私钥是保密的,防止了私钥外传;

  • 2、密钥功能: 公钥加密的数据,只可使用私钥对其解密。反之,私钥加密的数据,只可使用公钥对其解密(注意:公钥加密的数据无法使用公钥解密,因为公钥是公开的,如果公钥可以解密的话,就失去了加密的安全性);

  • 3、计算性能: 非对称加密算法的计算效率低,因此实际中往往采用两种算法结合的复合算法:先使用非对称加密建立安全信道传输对称密钥,再使用该密钥进行对称加密;

  • 4、认证功能: 非对称加密算法中,私钥只有一方持有,具备认证性和抗抵赖性(第 3 节 数字签名算法 应用了此特性)。

    扫描二维码关注公众号,回复: 15687649 查看本文章

考虑到性能的因素,在 HTTPS 协议中采用的是 “对称加密” 和 “非对称加密” 结合的 “混合加密” 方案 :在建立通信时,采用非对称加密的方式来协商 “会话密钥”,在通信过程中基于该密钥进行对称加密通信。

4.伪随机数和真随机数

随机数是计算机安全领域中非常重要的一个点,很多场景中都需要一个随机数来生成随机事件,比如密钥的生成、文件名、sessionId/orderId/token 等。现代的随机数生成模型依然采用的是 1946 年冯·诺依曼设计的随机数模型:

  • 1、输入任意一个数作为 “种子”,通过随机数算法得到一个随机数;
  • 2、将生成的随机数作为新的种子,代入下一轮计算;
  • 3、重复 1、2 步骤,就可以生成多个具有统计意义的随机数。

然而,通过这种模型生成的随机数并不是绝对随机的。只要取样范围足够大,随机结果一定会陷入循环,因此这种模型生成的随机数只能称为 “伪随机数”,而随机结果陷入循环的周期称为 “随机周期”。

要得到真正意义的随机数,需要硬件层面支持。

  • 1999 年 Intel 在其 i810 芯片组上集成了世界上第一款真随机数生成器,它的方案是将电路的热噪声(分子的不规则运动)作为数据来源,缺点是效率太低,因此目前计算机中采用的随机数依旧是软件实现的伪随机数。
  • 虽然软件无法做到真随机,但可以提高生成器的随机性。比如采用更强壮的随机算法(Java#SecurityRandom)、采用更复杂的种子(系统时间、鼠标位置、网络速度、硬盘读写速度)、扩大随机数的取值范围、组合多个随机算法等。

5.数字签名 —— 验证完整性 & 认证数据来源

数字签名(Digital Signature)也叫作数字指纹(Digital Fingerprint),它是消息摘要算法和非对称加密算法的结合体,能够验证数据的完整性,并且认证数据的来源。

数字签名算法的模型分为两个主要阶段:

  • 1、签名: 先计算数据的 [摘要],再使用私钥对 [摘要] 进行加密生成 [签名],将 [数据 + 签名] 一并发送给接收方;
  • 2、验证: 先使用相同的摘要算法计算接收数据的 [摘要],再使用预先得到的公钥解密 [签名],对比 [解密的签名的摘要] 和 [计算的摘要] 是否一致。若一致,则说明数据没有被篡改。
    在这里插入图片描述

如果用「公钥」对数据加密,用「私钥」去解密,这是「加密」; 反之用「私钥」对数据加密,用「公钥」去解密,这是「签名」。

  • 由于所有人都持有公钥,所以「签名」并不能保证数据的安全性,因为所有人都可以用公钥去解密。
  • 但「签名」却能用于保证消息的准确性和不可否认性。因为公钥和私钥是一一对应的,所以当一个公钥能解密某个密文时,说明这个密文一定来自于私钥持有者。

6.为什么使用摘要算法的数字签名可以验证完整性?

验证完整性主要依赖于消息摘要算法的特性,摘要算法的原理是根据一定的运算规则提取原始数据中的信息,被提取的信息就是原始数据的消息摘要,也称为数据指纹。

  • 对一份数据,进行一个单向的 Hash 函数,生成一个固定长度的 Hash 值,这个值就是这份数据的摘要
  • 著名的摘要算法有 MD5 算法和 SHA 系列算法。

摘要算法具有以下特点:

一致性: 相同数据多次计算的摘要是相同的,不同的数据(在不考虑碰撞时)的摘要是不同的;
不可逆性: 只能正向提取原始数据的摘要,无法从摘要反推出原始数据;
高效性: 摘要的生成过程高效快速;

摘要算法的模型分为两个主要步骤:

生成摘要: 先计算数据的 [摘要],再将 [数据 + 摘要] 一并发送给接收方;
验证摘要: 使用相同的摘要算法计算接收数据的 [摘要],对比 [收到的摘要] 与 [计算的摘要]是否一致。若一致,则说明数据是完整的。

单纯依靠摘要算法不能严格地验证数据完整性。因为在非安全信道中,数据和摘要都存在篡改风险,攻击者在篡改数据时也可以篡改摘要。因此,摘要算法需要配合加密算法才能严格验证完整性。

消息摘要的好处:

  • 例如我们在下载文件时,数据源会提供一个文件的MD5。文件下载好之后,我们本地计算出文件的MD5,和数据源提供的MD5做对比,如果相同则文件是完整的。 但独立使用消息摘要时,无法确保数据没有被篡改,因为无法保证从数据源获取的MD5有没有被中途篡改。
  • 相比加密算法,摘要算法速度都相对较快。

7.为什么数字签名可以认证数据来源?

这是因为签名时引入了发送方的私有信息(私钥),只有 ”合法的发送方“ 才能产生其他人无法伪造的一段数字签名(加密字符串),这个数字签名就证明了数据的真实来源。

  • 当接收方采用 ”合法途径“ 获得发送方的公有信息是(公钥),并且成功验证数字签名,那么正说明数据来自 ”合法的接收方“。
    另外,在签名时引入发送方私有信息,在验证时使用发送方公有信息,这正好符合 “非对称加密” 的特点。
    因为签名时引入的私有信息正是私钥,验证时使用的公有信息正式公钥。

8.可以先使用私钥对原数据签名,再对签名进行摘要吗?

不可以,主要有两个原因:

  • 1、可行性: 接收方需要通过摘要验证数据完整性,然而接收方无法对数据进行签名,因此无法验证数据摘要一致性;
  • 2、时间效率: 对原始数据进行签名(加密)时间太长,而摘要算法本身是压缩映射,可以缩短签名消耗的时间。

9.接收方怎样才能安全地获得发送方公钥呢?——数字证书

什么是数字证书?

  • 数字签名和数字证书总是成对出现,二者不可分离。数字签名主要用来验证数据完整性和认证数据来源,而数字证书主要用来安全地发放公钥。
  • 数字证书主要包含三个部分:用户的信息、用户的公钥和 CA 对该证书实体信息的签名。

数字证书的模型主要分为两个步骤:

  • 1、颁发证书:

(1) 申请者将签名算法、公钥、有效时间等信息发送给 CA 机构;
(2) CA 机构验证申请者身份后,将申请者发送的信息打成一个实体,并计算摘要;
(3) CA 机构使用自己的私钥对摘要进行加密,生成证书签名(Certificate Signature);
(4)CA 机构将证书签名添加在数字证书上,构成完整的数字证书。

  • 2、验证证书

(1) 验证方使用相同的摘要算法计算数字证书实体的摘要;
(2)使用 CA 机构的公钥(浏览器和操作系统中集成了 CA 的公钥信息)解密数字证书签名;
(3) 对比解密后的数据与计算的摘要是否一致,如果一致则是可信任的证书。

在这里插入图片描述

(1)生成CA根证书

根证书预先安装在操作系统中,我们认为根证书是一定正确的。
在这里插入图片描述
步骤:

    1. 权威机构利用RSA等算法,生成一对 公钥K1 / 私钥K2;
    1. 将 公钥K1 和 证书发布机构、有效期等信息组成一份原始的证书内容,设为 C;
    1. 利用某种摘要算法,计算原始内容 C 的数字摘要,设为 H;
    1. 用第一步生成的私钥S,对摘要H签名,得到签名内容S;
    1. 将原始内容C和 签名内容S 合在一起,就得到了CA根证书。

CA证书:CA机构颁发给其他人的证书。主要包含如下信息

  • 申请者公钥
  • 申请者的信息
  • 颁发者(CA)的信息
  • 以上信息的数字签名。 数字签名生成规则:先使用摘要算法,例如SHA256,将以上信息生成摘要,然后CA使用自己的私钥对此摘要加密

(2)业务相关证书的生成

在这里插入图片描述

    1. 企业利用RSA等算法,生成一对公钥K3 / 私钥K4;
    1. 将公钥K3和证书其他内容组成原始证书内容,设为C,给到权威机构;
    1. 权威机构拿到 C 后,利用摘要算法,生成摘要信息 2;
    1. 权威机构用自己的私钥K2 (这是关键点),对摘要信息H 签名,得到签名内容S;
    1. 将 原始内容C2 和 签名内容S2 合并到一起,得到证书,交给企业。

CA根证书和业务证书区别点在于: 业务申请的证书,在签名时用的私钥是CA机构的私钥。这个私钥是和根证书中的公钥对应的。

(3)数字证书的真伪验证

在这里插入图片描述

用根证书的公钥,可以验证其他证书的签名是否正确。如果签名正确,则证书是可信的、没有被篡改的。后续就可以使用这个被信任证书中包含的公钥,去验证收到的消息是否可信了。

10.什么是证书颁发机构 CA?

证书颁发机构(certifcation authroity, CA)是负责数字证书的审批、颁发、归档和吊销等功能的机构,具有权威性。

  • CA 机构分为 “根 CA” 和 “中间 CA”,原则上要避免根 CA 机构直接颁发最终实体证书,而需要由中间 CA 机构颁发最终实体证书。
  • 这是为了避免证书失效的影响范围,一旦根证书失效或被伪造,那么整个证书链都有问题。

11. 什么是证书链?

证书链是多个数字证书建立的的证书验证链条。

  • 数字证书主要包含三个部分:用户信息、用户密钥以及 CA 机构对该证书实体的签名。
  • 为了验证证书实体的合法性,需要获得颁发该证书的 CA 机构公钥,这个公钥就存在于上一级证书中。因此,为了验证证书的合法性,就需要沿着证书链向上追溯直到根证书为止。

根证书是自签名证书,用户下载根证书就表示信任该根证书所有签发的证书。在操作系统或浏览器中,已经内置了一部分受信任的根证书。

在这里插入图片描述

12.数字证书的标准

数字证书主要包含三个部分:用户的信息、用户的公钥和 CA 对该证书实体信息的签名。目前的数字证书采用的是公钥基础设施(PKI)制定的 X.509 标准,目前已经有 3 个版本,其中比较常见的是 X.509 第三版的标准。

  • 主要格式如下:
    在这里插入图片描述

二、openssl生成自签名证书

基本流程

搞一个虚拟的CA机构,生成一个证书
生成一个自己的密钥,然后填写证书认证申请,拿给上面的CA机构去签名
于是就得到了自(自建CA机构认证的)签名证书

  • 根证书是https客户端内置的,由https服务端私有密钥生成的
    在这里插入图片描述

首先,虚构一个CA认证机构出来

# 生成CA认证机构的证书密钥key
# 需要设置密码,输入两次
openssl> genrsa -des3 -out ca.key 1024

# 去除密钥里的密码(可选)
# 这里需要再输入一次原来设的密码
openssl> rsa -in ca.key -out ca.key

# 用私钥ca.key生成CA认证机构的证书ca.crt
# 其实就是相当于用私钥生成公钥,再把公钥包装成证书
openssl> req -new -x509 -key ca.key -out ca.crt -days 365
# 这个证书ca.crt有的又称为"根证书",因为可以用来认证其他证书

生成网站的证书

  • 用上面那个虚构出来的CA机构来认证
# 生成自己网站的密钥server.key
# genra	生成RSA私钥
# -des3	des3算法
# -out server.key 生成的私钥文件名
# 1024 私钥长度
openssl> genrsa -des3 -out server.key 1024

# 生成自己网站证书的请求文件
# 如果找外面的CA机构认证,也是发个请求文件给他们
# 这个私钥就包含在请求文件中了,认证机构要用它来生成网站的公钥,然后包装成一个证书
# req 生成证书签名请求
# -new 新生成
# -key 私钥文件
# -out 生成的CSR文件
# -subj 生成CSR证书的参数
openssl> req -new -key server.key -out server.csr -subj "/C=CN/ST=Guangdong/L=Guangzhou/O=xdevops/OU=xdevops/CN=gitlab.xdevops.cn"

# 使用虚拟的CA认证机构的证书ca.crt,来对自己网站的证书请求文件server.csr进行处理,生成签名后的证书server.crt
# 注意设置序列号和有效期(一般都设1年)
# -days 证书有效期
openssl> x509 -req -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -days 365 

至此,私钥server.key和证书server.crt已全部生成完毕,可以放到网站源代码中去用了

  • subj参数说明如下:
    在这里插入图片描述

三、Android 的应用签名

Gradle(10)一篇文章看懂 v1/v2/v3 签名机制

https://duanqz.github.io/2017-01-04-Package-Manage-Mechanism

四、HTTPS双向认证(Mutual TLS authentication)

HTTPS双向认证(Mutual TLS authentication)

参考:

猜你喜欢

转载自blog.csdn.net/u011436427/article/details/130928501