哈工大密码学实验CA

写在前面的话，今天是2021.12.19，密码学实验已验收，符合全部要求，本文是实验报告，仅供学弟学妹参考

1.背景与意义

1.1 项目开发意义

随着以信息网络技术为代表的科学技术的迅猛发展，21 世纪，我们已步入了一个以电子商务为核心的数字化革命时代，全球经济一体化程度进一步加强，金融企业的经营环境发生了巨大变化。随之而来的是我们生活方方面面的巨大改变。
电子商务的重要特点是使用IT技术进行信息传递和数据处理。所以,电子商务安全应该包含两方面:一方面是计算机网络安全,另一方面是商务交易安全。商务交易安全需要围绕传统商务在互联网中应用存在的安全隐患,基于计算机网络安全基础,确保电子商务过程顺利进行。这样能够确保电子商务保密性、完整性、可靠性等目标如期实现。就计算机网络安全来看，其与电子商务交易安全之间也是密切相关的,两者相互影响、相辅相成,必须构建比较完善的计算机网络安全体系和电子商务交易安全体系。
电子商务在应用中的信息泄露问题比较多,这主要是因为贸易双方的信息没有得到有效保护。例如在非法攻击和窃取相关信息的过程中,一是通过窃听手段对于传输路径中的数据进行拦截、监听等,以获取其中有价值的信息，导致信息泄露;二是借助数据库服务器发现Web程序和网络数据库的漏洞。一些网络攻击者借助数据库攻击、窃听的方式非法获取商务活动的用户信息。一些攻击者会使用合法用户信息和身份与其他人进行交易,以谋取非法权益,这样不仅会破坏贸易的可靠性,还会损坏贸易者的信誉。简单来说，在一个网络购物过程中，我们会想知道：购物的网站可信吗？我存储钱的网站可信吗，会不会是一个钓鱼网站。为了解决这个信任问题，由此我们便引出一个第三方认证——CA认证中心。
CA是认证中心的英文Certification Authority的缩写。　CA中心，又称为数字证书认证中心。CA中心作为电子交易中受信任的第三方，负责为电子商务环境中各个实体颁发数字证书，以证明各实体身份的真实性，并负责在交易中检验和管理证书；数字证书的用户拥有自己的公钥/私钥对。证书中包含有证书主体的身份信息、其公钥数据、发证机构名称等，发证机构验证证书主体为合法注册实体后，就对上述信息进行数字签名，形成证书。 在公钥证书体系中，如果某公钥用户需要任何其它已向CA注册的用户的公钥，可直接向该用户索取证书，而后用CA的公钥解密解密即可得到认证的公钥；由于证书中已有CA的签名来实现认证，攻击者不具有CA的签名密钥，很难伪造出合法的证书，从而实现了公钥的认证性。 数字证书认证中心是整个网上电子交易安全的关键环节,是电子交易中信赖的基础。他必须是所有合法注册用户所信赖的具有权威性、信赖性及公正性的第三方机构。
在SET交易中，CA不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。也可说，没有第三方认证的存在，安全电子交易便不存在。

1.2 国内外现状及技术综述

目前数字证书，作为一种比较成熟的安全产品，数字证书已经发展到一个较高的技术水平，而且它将在我们将来的网络生活中发挥越来越重要的作用。通俗地讲，数字证书就是个人或单位在 Internet上的身份证。比较专业的数字证书定义是，数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间，发证机关（证书授权中心）的名称，该证书的序列号等信息，证书的格式遵循相关国际标准。有了数字证书，我们在网络上就可以畅通无阻。数字证书需要十分可靠的安全保密技术，也就是说，必须保证网络安全的四大要素，即信息传输的保密性、数据交换的完整性、发送信息的不可否认性、交易者身份的确定性。
ca技术在电子商务的领域应用的越来越普遍，大部分的商家和企业选择的都是因为它的安全性，可是与外国发达，我国的数字证书尚在起步阶段，很多企业只是在这一领域里进行尝试，而且也难怪显出各司其职的鱼龙混杂的现象，所以进一步完善我们的数字证书领域是非常迫切的，而且，我们国家也需要这方面的人才。目前，我国的若认证机构分布在天津、北京、上海、广州湖南、湖北、山西等地。
X.509标准是密码学里公钥证书的格式标准。X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Internet协议里，同时它也有很多非在线的应用场景，比如电子签名服务。X.509证书含有公钥和标识（主机名、组织或个人），并由证书颁发机构（CA）签名（或自签名）。对于一份经由可信的证书签发机构签名（或者可以通过其它方式验证）的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，以及对文档进行数字签名。
X.509最早与X.500一起发布于1988年7月3日，它假定颁发证书的证书颁发机构（CA）具有严格的层次结构。这与Web信任模型（如PGP）形成了鲜明对比，因为PGP方案是任何人都以签名（而不仅仅是地位特殊的CA），从而证明其他人的密钥证书的有效性。X.509 V3证书的设计非常灵活，除了对网桥拓扑架构网络的支持，还可以支持用于点对点方式的Mesh网，类似于OpenPGP那样的web信任机制，不过这样方式在2004年之前很少使用。
在X.509系统中，证书申请者通过发起“证书签名请求（CSR）”来得到一份被签名的证书。为此，它需要生成一个密钥对，然后用其中的私钥对CSR签名（私钥本身要妥善保存，对外保密），CSR包含申请人的身份信息、用于验真CSR的申请人的公钥，以及所请求证书的专有名称（DN），CSR还可能带有CA要求的其它有关身份证明的信息，然后CA对这个专有名称发布一份证书，并绑定一个公钥。
组织机构可以把受信的根证书分发给所有的成员，这样就可以使用公司的PKI系统了。像Firefox, IE, Opera, Safari 以及Google Chrome这些浏览器都预装了一组CA根证书，所以可以直接使用这些主流CA发布的SSL证书。浏览器的开发者直接影响它的用户对第三方的信任。FireFox就提供了一份csv/html格式的列表。X.509还包括证书吊销列表（CRL）实现标准，这是PKI系统经常被忽略的方面。IETF批准的检查证书有效性的方法是在线证书状态协议（OCSP），Firefox 3默认情况下启用OCSP检查，从Vista开始的高版本Windows也是如此。

2.需求分析

2.1 总体需求

完成一个认证系统的相关所需功能，本CA认证系统需可供商家、用户、银行等各个用户进行申请证书认证，每个申请用户均需在系统注册身份账号后申请证书，在网站申请页面填写正确信息后，由系统进行申请审核通过后，签发格式为cer的证书，并分配私钥，证书及私钥分发途径为系统提供下载接口，申请用户直接下载后加入本网站中使用，此外，系统提供使用方法的相关函数，商家或银行可根据相关方法并结合自己需求后正确使用自己的证书。
CA系统在各方面涉及到用户信息的地方要进行加密，防止信息泄露，同时对证书，私钥的保存，撤销收回等方面拥有管理权。用户拥有对自己信息查看修改等权力。
此外，系统会记录用户的操作，生成系统日志，便于管理员复核和审计。

2.2 功能需求

2.2.1系统功能

1)注册：用户名和密码，开通CA账户（用户的用户名不能相同，用户可并非真实名字）
2)登录：输入正确的用户名和密码进行登录CA系统
3)填充/查看/修改详细信息（CN、OU、O、L、邮箱等……）
4)证书申请：用户点击认证申请，在申请界面，输入相关完整信息，系统审核成功后，进行分发证书
5)下载证书及相关文件：保存网站生成的口令，输入口令解密私钥，保障私钥传输安全；分别有三个链接下载证书、公钥和私钥；点击安全清除按钮，保障私钥传输安全
6)签名及验证的使用方法：点击下载链接，下载三个文件，按照使用方法正确使用证书即可
7)申请撤销证书：需要修改证书信息或者私钥泄露时撤销证书
8)私钥恢复机制：当用户本地丢失私钥时，可向系统提供身份证明再次查看私钥
9)查询证书（有效性检查）：查看/下载其他用户的CA证书信息，非法用户/该用户最新证书过期提醒
10)日志功能：记录系统中每一步操作，生成操作日志，供管理员审核，复查

2.2.2系统安全

账户安全：
1)用户的密码信息，不以明文方式存储，哈希后进行传输与存储，对用户密码进行存储安全处理；传输时用对称密钥以及公私密钥加密，保障传输安全
2)用户的相关资料不能被其他人查看。只有本人登陆后才可查看
3)只有上传个人资料管理员审核之后才能允许申请下载证书。所有账户必须保证身份信息真是可靠
传输安全：
1)加密相关操作均在传输前进行加密，保证传输中被窃听，相关信息不被泄露
2)私钥传输时也经过相关加密，在传输中不会保障安全，在客户端解密、被客户安全下载后安全删除相关文件，只保留用户本地文件
数据库安全
1)数据库作为信息存储的重要平台，需要有加密技术支持，备份防丢失
私钥存储安全
1)使用最小权限原则：加强对系统和网络访问的身份验证;阻止除必要网络端口之外的其他所有网络端口；安装所有可用的安全更新并运行防病毒扫描程序。
2)密钥存储在安全的加密硬件设备中：密钥最好不要存储在通用计算机上，这样容易受到攻击。加密的硬件设备不易受到攻击，并受到大多数重要应用程序的信任。

2.3 性能需求

1.可以与电商平台以及银行连接；
2.系统可以 24 小时不间断工作；
3.用户认证过程需要安全可靠，速度快，普通用户登录时间小于 2s；

3.概要设计

3.1开发环境

操作系统：Windows 10
数据库：Mysql
语言：java + html + jsp + css
框架：vue框架

3.2业务数据流

用户注册账户=>注册证书相关详细信息 => 用户申请证书 => 系统审核 => 分发公私钥下载接口和证书下载接口，且提供使用方法和相关函数 => 用户根据相关方法和自己的需求使用

3.3数据库设计

第一张表：账户信息表

Username采用明文存储
Password 采用哈希后的密文存储
例如：

第二张表：证书相关信息表，设计如下

例如：

第三张表：保存公钥

例如：

3.4证书结构及设计

3.4.1证书格式

X.509，所有的证书都符合ITU-T X.509国际标准。
X.509证书的结构是用ASN1(Abstract Syntax Notation One)进行描述数据结构，并使用ASN.1语法进行编码。X.509标准定义了证书中应该包含哪些信息，并描述了这些信息是如何编码的(即数据格式)
目前使用最广泛的标准为ITU和ISO联合制定的X.509的 v3版本规范 (RFC5280）, 其中定义了如下证书信息域：
1)版本号(Version Number）：规范的版本号，目前为版本3，值为0x2；
2)序列号（Serial Number）：由CA维护的为它所发的每个证书分配的唯一的列号，用来追踪和撤销证书。只要拥有签发者信息和序列号，就可以唯一标识一个证书，最大不能过20个字节；
3)签名算法（Signature Algorithm）：数字签名所采用的算法，如：sha256-with-RSA-Encryption、ccdsa-with-SHA2S6
4)颁发者（Issuer）：发证书单位的标识信息，如 “ C=CN，ST=Beijing, L=Beijing, O=org.example.com，CN=ca.org。example.com ”；
5)有效期(Validity): 证书的有效期很，包括起止时间。
6)主体(Subject) : 证书拥有者的标识信息（Distinguished Name），如：" C=CN，ST=Beijing, L=Beijing, CN=person.org.example.com “ ；
7)主体的公钥信息(SubJect Public Key Info）：所保护的公钥相关的信息：
1.公钥算法 (Public Key Algorithm）公钥采用的算法
2.主体公钥：公钥的内容
3.颁发者唯一号：代表颁发者唯一信息（可选）
4.主体唯一号：代表拥有实体证书的唯一信息（可选）
5.扩展

3.4.2证书设计

为了更加深入理解签名这一过程，增加一个扩展，对用户名进行签名（用户名在本系统中每个人有且只有一个，互不相同，相当于一种身份象征）保存至使用者密钥标识符中，如下：

该签名可通过验证，若有人伪造证书，则会被发现。
用户生成证书时，需要向CA提交相关信息（实际情况中，用户本人可能需要带上相关文件向CA提供申请者真实性的证明，若缺少文件或者文件存在问题则拒绝颁发证书，但在此系统中，默认用户都是“好人”，“坏人”不会来申请证书）CA自动生成后将文件放在服务器本地（服务器认为是被加密后的，坏人不会攻破本地文件），生成文件夹结构如下所示

其他文件夹内容类似，在此不进行展示

4.实验流程总览

4.1注册设计

输入网址进入登录页面（更改hosts文件，将IP放入“本地服务器”，可跳过）

点击注册一个，转跳至注册页面

信息完整性：即时检测，密码与确认密码必须一致，三者不能为空

按照要求可成功注册


点击确认后直接跳转至登录页面

4.2登录设计

成功登录后进入用户页面，左边有工作面板

4.3完善基本信息设计

按照实际情况填写后点击提交信息，这里为了演示全部填写example

4.4查看信息的设计

4.4.1查看自己的证书信息

4.4.2查询别人的证书信息

输入要查询的用户名（在本系统中，用户名类似于身份证那种象征身份的东西，每个用户均不同）若查询对象存在且证书有效，则可以查看信息、下载证书和公钥

4.5修改信息设计

修改页面如下，再次填写信息可覆盖以前信息，为了演示我全部修改成examplee

再次查询发现已经改变

4.6申请且下载证书（私钥的安全传输）

页面如下

第一步，为了保障私钥的传输安全，需要一个随机生成的密钥加密私钥文件，点击第一个按钮，会得到密钥，保存下来。

第二步，将得到的口令输入口令框

第三步，点击按钮进行安全解密密钥文件，第四步就可以下载后端传来的文件（私钥经过安全传输）
公钥文件（通过证书也可以获得，在使用方法中详细写了如何从证书获取公钥的相关代码）由于修改过一次，有上一次的公钥记录（但上一次的公钥已失效）

私钥文件（只有最后一次有效的私钥）：

证书文件：可以看到是刚刚生成的examplee

最后一步，点击安全清除按钮，将前端私钥文件清除掉，防止私钥泄露，注：在下面附有使用方法，点击可以下载

4.7撤销证书

阅读须知后选择已阅读，即可提交撤销申请，后端会自动更改CRL。

5.详细设计

在上一节已经看过一个完整的实验流程，下面详细说明设计中的安全细节与实现。

5.1注册时的安全

用户注册时，输入的用户名和密码属于敏感信息，不应该用明文传输（传输时的安全，即敌手不会在信道中通过直接抓包获得用户名和密码）其次，如果只是每次生成一个会话密钥，使用AES对称密钥加密，敌手在有限的时间内也可以破解密码，所以，应使用对称密钥加非对称密钥加密方案（混合加密方案），对称密钥每一次现生成，非对称密钥选取CA证书中的公私钥，最后，密码存在数据库不应是明文，否则会产生不安全问题（数据库泄露或者管理数据库的工作人员泄露敏感信息）故密码应经过单向函数（哈希函数）散列后放入数据库中，过程如下。

会话密钥（对称密钥）是临时生成的，每一次的密钥随机生成且概率相等的，否则会有安全问题，其次，对称加密使用AES加密方法，DES已经不再安全。
非对称加密的公私钥应是经过CA签名认证的，发送方应确认自己得到的确实是对方的证书，且该证书有效（未过期且私钥未泄露）非对称加密方案使用RSA加密方案。签名方案我使用了SHA256withRSA。

5.2登录时的安全

登录时的加密过程与上述相同，数据传到后端后与数据库中存储的哈希值做对比，相同则登录成功，不同则登录失败；其次，如果用户没有经过登录页面的“审核”，直接通过改变URL企图绕开登录页面，将不能做多余的事情（即更改信息等），只被允许查询他人证书（游客模式？）。

5.3私钥安全

现在我们假设example已经提交了申请证书需要的信息，需要申请证书获得证书文件和私钥文件，证书文件和公钥都是公开的，可以用明文传输，但是私钥文件应该如何安全传递呢？自然而然的就想到了用上述方式（5.1）加密文件，但作为CA系统为对方颁发证书，对方的证书还没有传递给对方，即对方还没有自己的私钥，不能用对方的公钥加密，那用自己的私钥加密（签名）可以吗？当然也是不行的，作为CA，任何人都可以获得CA的公钥，而获得CA公钥的人都可以解密该文件，即任何人都可以解密私钥文件。
所以在此，我只能退而求其次，仅仅用对称加密方法加密该文件，会话密钥就是每一次需要保存的密钥（4.5第一步）。下面展示文件在每一时刻的状态。
第一，填充完申请证书的必要信息之后，申请证书，后端生成的密钥文件存到本地（现实生活中，密钥存储在安全的加密硬件设备中，加密的硬件设备不易受到攻击，并受到大多数重要应用程序的信任，其次，为私钥设置复杂的保护密码）
第二，点击第一个按钮，此时私钥文件已经从后端传送过来了，存在前端public\lab_certificate中，但是是以密文的方式存储，如下：

第三，此时输入口令，按下按钮。这时相当于将会话密钥传递到前端，前端对存储加密文件进行解密，用户应该迅速下载私钥文件，因为此时，私钥其实是不安全的。
第四，按下第四个按钮，将前端解密后的文件彻底清除，私钥此时不再暴露。
这里，我需要声明，第一，认为 CA是完全可信的，即CA不会被敌手攻破，密钥存储在CA本地是安全的；第二，私钥在传输过程中，会话密钥暴露的概率忽略不计，即认为私钥在传输过程中是安全的；第三，用户在下载完私钥文件之后会立刻按下安全清除按钮，即认为敌手不会在用户下载私钥的同时下载私钥文件，若满足以上三个条件，则保证私钥传输过程是安全的。
下面讲述实现私钥安全的另一种方法，即在客户端生成公私钥，具体做法如下：
第一，CA提供公私钥生成器。
第二，客户在本地生成公私钥，将私钥也保存在本地。这就不必在信道传输私钥文件了。
第三，客户直接将公钥传输给服务器，服务器根据公钥以及申请信息进行一系列签名，生成证书。
第四，服务器将证书传输给客户端。
完成申请证书操作。

5.4使用证书

5.4.1签名的实现

本系统使用SHA256withRSA方法进行签名，具体代码放在SHA256withRSAUtil类中，里面包含两种不同的签名/验证签名的实现，均已通过验证。

5.4.2证书的有效性查询

查询证书的有效性，在本系统中有两个判断准则：第一，证书是否过期；第二，证书是否由CA本系统颁发。
过期检测：每一个证书在生成时默认有效期为10天，从生成时立即生效。有效期信息记录在数据库中，当用户查询其他用户的证书时，后端会检查当前时刻与过期日期，判断该证书是否过期。若过期，则立刻删除证书，返回前端证书已过期的提示；若未过期，则正常返回信息。
检查证书是否由CA本系统颁发：生成证书的时候，每份证书均经过CA本系统的签名，用户可通过下载本系统提供的使用方法（SHA256withRSAUtil类）验证是否由本系统签名。具体使用方法，均已在SHA256withRSAUtil类中写明。

5.4.3利用证书进行非对称加密

本系统使用RSA方法加密，两套具体代码放在RsaUtil类以及CARSA类中，均已通过验证。

5.5其他

5.5.1AES加密

对称加密AES方法在后端也有两套放在了AESUtile以及AESFileUtil类中，分别加解密字符串以及文件。前端在Utils里的secret.js里也有相应实现。

5.5.2日志

记录的日志放在log文件夹下

里面对每一个用户的信息都进行了清楚的记录


其他细节请看详细代码。