Linux高级篇–数据安全与加密算法
一、 数据安全与加密算法
1.1 数据加密
安全机制
- 信息安全防护的目标
保密性 Confidentiality
完整性 Integrity
可用性 Usability
可控制性 Controlability
不可否认性 Non-repudiation - 安全防护环节
物理安全:各种设备/主机、机房环境
系统安全:主机或设备的操作系统
应用安全:各种网络服务、应用程序
网络安全:对网络访问的控制、防火墙规则
数据安全:信息的备份与恢复、加密解密
管理安全:各种保障性的规范、流程、方法
关于数据安全
- 安全攻击: STRIDE
Spoofing 假冒
Tampering 篡改
Repudiation 否认
Information Disclosure 信息泄漏
Denial of Service 拒绝服务
Elevation of Privilege 提升权限
安全算法
- 常用安全技术
认证
授权
审计
安全通信 - 密码算法和协议
对称加密
公钥加密
单向加密
认证协议
1.2 加密算法
对称加密算法
- 对称加密:加密和解密使用同一个密钥
DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5 - 特性:
1、加密、解密使用同一个密钥,效率高
2、将原始数据分割成固定大小的块,逐个进行加密 - 缺陷:
1、密钥过多:由于加密、解密使用同一密钥,因此与不同的人通信就需要一个密钥;
2、密钥分发:密钥的安全传输无法解决;
3、数据来源无法确认:一旦其他人得知加密方法,无法确认数据来源是否可信
非对称加密算法
- 公钥加密:密钥是成对出现
公钥:公开给所有人;public key
私钥:自己留存,必须保证其私密性;secret key - 特点:用公钥加密数据,只能使用与之配对的私钥解密;反之亦然
- 功能:
数字签名:主要在于让接收方确认发送方身份
对称密钥交换:发送方用对方的公钥加密一个对称密钥后发送给对方
数据加密:适合加密较小数据 - 缺点:密钥长,加密解密效率低下
- 算法:
RSA(加密,数字签名)
DSA(数字签名)
ELGamal
非对称加密详解
- 基于一对公钥/密钥对
用密钥对中的一个加密,另一个解密 - 实现加密:
接收者
生成公钥/密钥对:Public和Secure(以下简称P和S)
公开公钥P,保密密钥S
发送者
使用接收者的公钥来加密消息M
将P(M)发送给接收者
接收者
使用密钥S来解密:M=S(P(M)) - 实现数字签名:
发送者
生成公钥/密钥对:P和S
公开公钥P,保密密钥S
使用密钥S来加密消息M
发送给接收者S(M)
接收者
使用发送者的公钥来解密M=P(S(M)) - 结合签名和加密
- 分离签名
总结:
数据传输无外乎两方面内容:1、数据的安全传输 2、数据的来源可靠
假设A和B进行通信,A用B的公钥加密数据,该数据只能由B用自己的私钥机密,这就确定了数据的安全传输。
而数据签名是A用自己的私钥加密数据,B如果能用A的公钥解密,即可确定数据来源为A,这就确保了数据来源的可信度。
单项散列(哈希算法)
- 将任意数据缩小成固定大小的“指纹”
任意长度输入
固定长度输出
若修改数据,指纹也会改变(“不会产生冲突”)
无法从指纹中重新生成数据(“单向”) - 功能:数据完整性
- 常见算法
md5: 128bits、sha1: 160bits、sha224 、sha256、sha384、sha512 - 常用工具
md5sum | sha1sum [ --check ] file
openssl、gpg
rpm -V
二、 数据加密命令gpg
应用程序:RPM
- 文件完整性的两种实施方式
- 被安装的文件
MD5单向散列
rpm --verify package_name (or -V) - 发行的软件包文件
GPG公钥签名
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat*
rpm --checksig pakage_file_name (or -K)
使用gpg实现对称加密
- 对称加密file文件
gpg -c file
ls file.gpg - 在另一台主机上解密file
gpg -o file -d file.gpg
使用gpg工具实现公钥加密
- 在hostB主机上用公钥加密,在hostA主机上解密
- 在hostA主机上生成公钥/私钥对
gpg --gen-key - 在hostA主机上查看公钥
gpg --list-keys - 在hostA主机上导出公钥到wang.pubkey
gpg -a --export -o wang.pubkey - 从hostA主机上复制公钥文件到需加密的B主机上
scp wang.pubkey hostB: - 在需加密数据的hostB主机上生成公钥/私钥对
gpg --list-keys
gpg --gen-key - 在hostB主机上导入公钥
gpg --import wang.pubkey
gpg --list-keys - 用从hostA主机导入的公钥,加密hostB主机的文件file,生成file.gpg
gpg -e -r wangxiaochun file
-e 加密
-r 指定接受信息的人
file file.gpg - 复制加密文件到hostA主机
scp fstab.gpg hostA: - 在hostA主机解密文件
gpg -d file.gpg
gpg -o file -d file.gpg - 删除公钥和私钥
gpg --delete-keys wangxiaochun
gpg --delete-secret-keys wangxiaochun
三、 PKI和CA
3.1 为何需要PKI和CA
中间人攻击流程
client端向server端请求公钥,中间人截获该请求,向server端请求公钥
server端把真公钥发送给CLIENT端,中间人截获真公钥,把自己的假公钥发送给client端
client端使用假公钥加密数据发送给server端,中间人截获由假公钥加密的数据,用自己的私钥解密数据并篡改,再用真公钥加密把假的数据发送给server端
server端使用真公钥加密加密数据再次发送给client端,中间人截获数据后进行篡改,然后使用自己的假公钥加密数据,发送给client端,而此时client端看到的数据则为中间人篡改后的数据
这样,中间人就获取到了A和B通信的信息
存在问题:此过程说明了公钥的传输仍然存在着漏洞
解决方法:采用权威认证机构发布的CA认证证书传递公钥
采用CA公钥传递过程
A和B通讯,寻找可信的权威机构
A把自己的公钥发送给CA,CA拥有自己的公钥和私钥,通过审核后,CA用自己的私钥对A的公钥做数字签名(除了数字签名还包括CA信息,A的信息、有效期),这些信息就是所谓的CA证书,CA把此证书颁发给A;
此时,假设B已经获取CA的公钥信息,那么通过解密证书文件,即可获取A的公钥信息;以此类推,A通过CA证书获取B的公钥信息最权威的CA证书颁发机构根CA(顶层CA)有自己的公钥和私钥;子CA通过向根CA申请获取证书,在上述过程中,假设B获得CA公钥信息,此时A和B获取的CA公钥为根CA颁发的公钥,此公钥是必须可信的,因此确保了CA公钥的可信度
在安装windows系统时,知名机构的公钥已经被安装在系统中,即获取了根CA的公钥,那么子CA颁发的证书也就确保了可信度
CA和证书
- PKI: Public Key Infrastructure
签证机构:CA(Certificate Authority)
注册机构:RA
证书吊销列表:CRL
证书存取库: - X.509:定义了证书的结构以及认证协议标准
版本号
序列号
签名算法
颁发者
有效期限
主体名称
证书获取
- 证书授权机构的证书
服务器
用户证书 - 获取证书两种方法:
使用证书授权机构
生成签名请求(csr)
将csr发送给CA
从CA处接收签名
自签名的证书
权威认证机构只能自已签发自己的公钥
安全协议
- SSL: Secure Socket Layer(安全套接层)
- TLS: Transport Layer Security(传输层安全协议)
1995:SSL 2.0 Netscape
1996: SSL 3.0
1999: TLS 1.0
2006: TLS 1.1 IETF(Internet工程任务组) RFC 4346
2008:TLS 1.2 当前使用
2015: TLS 1.3
功能:机密性,认证,完整性,重放保护
重放:不解密数据,把数据截取下来重新发送该数据,利用截取的数据假冒数据发送方把数据发送给接收方以获取其信息
- 两阶段协议,分为握手阶段和应用阶段
握手阶段(协商阶段):客户端和服务器端认证对方身份(依赖于PKI体系,利用数字证书进行身份认证),并协商通信中使用的安全参数、密码套件以及主密钥。后续通信使用的所有密钥都是通过MasterSecret生成。
应用阶段:在握手阶段完成后进入,在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信
https工作过程
- https工作过程:
1、客户端client向服务端server发出请求,要登录https://www.domain.com
2、服务端把已经拥有的证书发送给客户端,该证书内容包括服务端自己的公钥、ca的私钥签名、网站信息、证书有效期;而且该证书已经用数字签名(即使用CA的私钥加密)保证其来源的可靠性
3、客户端信任CA,使用已经获取的CA的公钥进行解密,获取证书中服务端的公钥,此公钥确定是可靠可信的
4、客户端生成随机字符串session key(即会话密钥,也叫对称密钥),使用服务端的公钥加密随机字符串key,传递给服务端
5、服务器使用自己的私钥解密公钥加密的数据,获取key
6、随后,通讯双方即可使用key加密数据进行通讯
3.2 OpenSSL命令实现加密和创建CA
openssl
- OpenSSL:开源项目
三个组件:
openssl: 多用途的命令行工具,包openssl
libcrypto: 加密算法库,包openssl-libs
libssl:加密模块应用库,实现了ssl及tls,包nss - openssl命令:
两种运行模式:交互模式和批处理模式
openssl version:程序版本号
标准命令、消息摘要命令、加密命令
标准命令:
enc, ca, req, …
openssl命令实现加密
- 对称加密:
工具:openssl enc, gpg
算法:3des, aes, blowfish, twofish - enc命令:
帮助:man enc
加密:
openssl enc -e -des3 -a -salt -in testfile
-out testfile.cipher
解密:
openssl enc -d -des3 -a -salt –in testfile.cipher
-out testfile
openssl ? - 单向加密:
工具:md5sum, sha1sum, sha224sum,sha256sum…
openssl dgst
[root@centos7-1 data]#md5sum fstab
961c41cf7e266c35a8acb08022c3fd0a fstab
[root@centos7-1 data]#openssl dgst -md5 fstab
MD5(fstab)= 961c41cf7e266c35a8acb08022c3fd0a
算法一致,结果也一致
[root@centos7-1 data]#openssl dgst -sha fstab
SHA(fstab)= 732fb007d706f6410b3b9e6189ebf5c4053e4102
[root@centos7-1 data]#openssl dgst -sha1 fstab
SHA1(fstab)= 6de655ee1b0a7cbfce29d244dba56a990b7b79df
注意sha算法中,sha算法和sha1算法不同
- dgst命令:
帮助:man dgst
openssl dgst -md5 [-hex默认] /PATH/SOMEFILE
openssl dgst -md5 testfile
md5sum /PATH/TO/SOMEFILE - MAC: Message Authentication Code,单向加密的一种延伸应用,用于实现网络通信中保证所传输数据的完整性机制
CBC-MAC
HMAC:使用md5或sha1算法 - 生成用户密码:
passwd命令:
帮助:man sslpasswd
openssl passwd -1 -salt SALT(最多8位)
openssl passwd -1 –salt centos
openssl passwd -l 输入密码,生成加密的随机字符,由于加的盐不同,即使密码相同,生成的字符串也不相同
[root@centos7-1 data]#openssl passwd -1
Password:
Verifying - Password:
$1$6xpH2Wqj$i7MsvvvrzmAZrVG1tfd8K1
[root@centos7-1 data]#openssl passwd -1
Password:
Verifying - Password:
$1$2rhWY8eg$PUrw57YH.8ifw9g1tFykQ0
可以通过指定盐,相同的密码会生成相同的随机字符串
[root@centos7-1 data]#openssl passwd -1 -salt 1$2rhWY8eg
Password:
$1$1rhWY8eg$Xr3rR0UjxAthuQtJwdVp/.
[root@centos7-1 data]#openssl passwd -1 -salt 1$2rhWY8eg
Password:
$1$1rhWY8eg$Xr3rR0UjxAthuQtJwdVp/.
- 生成随机数:
帮助:man sslrand
openssl rand -base64|-hex NUM
NUM: 表示字节数;-hex时,每个字符为十六进制,相当于4位二进制,出现的字符数为NUM*2
base64编码详解:
openssl rand -base64 N 生成N字节的随机数
基于base64生成的随机数,64为2^6
一个字节占8位,如果N*8能够被6整除,那么生成的随机数后不带=号(当随机数不够时,会使用=号占位),如果N*8不能被6整除,则生成的随机数后会有=号补全
[root@centos7-1 data]#openssl rand -base64 3 3*8=24,能够被6整除
1hBC
[root@centos7-1 data]#openssl rand -base64 6 6*8=48,能够被6整除
CWXZ8A7Z
[root@centos7-1 data]#openssl rand -base64 5 5*8=40,不能够被6整除
l6y7GxA=
[root@centos7-1 data]#openssl rand -base64 11
ghFJ452U9n2kV6k=
base64编码,使用64个字符表示系统中的二进制
64字符 对应二进制(这里用十进制表示,方便理解)
A-Z 0-25
a-z 26-51
0-9 52-61
+ 62
/ 63
[root@centos7-1 data]#echo -n "ab"|base64
YWI=
如a,十进制为97,二进制为01100001
如b 98 01100010
64为2^6,即使用6位表示
二进制: 011000 01 0110 0010 00 以6位分割,最后缺少两位用00补齐
十进制: 24 22 8
base64编码: Y W I= 根据64字符与二进制对应表得出
由于二进制最后两位没有,是补出来的,因此base64编码中在I后加上=号,即YWI=
[root@centos7-1 data]#echo -n "abc"|base64
YWJj
二进制: 011000 01 0110 0010 011 00011 00
十进制: 24 22 9 35
base64编码: Y W J j
abc,一个字符占8位,三个字符24位,能够被6整除,因此base64编码中没有=号,而YWJj用同样的计算方法可以计算得出
- 公钥加密:
算法:RSA, ELGamal
工具:gpg, openssl rsautl(man rsautl) - 数字签名:
算法:RSA, DSA, ELGamal - 密钥交换:
算法:dh
DSA: Digital Signature Algorithm
DSS:Digital Signature Standard
RSA: - 生成密钥对儿:man genrsa
- 生成私钥
openssl genrsa -out /PATH/TO/PRIVATEKEY.FILE NUM_BITS
(umask 077; openssl genrsa –out test.key –des 2048)
openssl rsa -in test.key –out test2.key 将加密key解密 - 从私钥中提取出公钥
openssl rsa -in PRIVATEKEYFILE –pubout –out PUBLICKEYFILE
openssl rsa –in test.key –pubout –out test.key.pub - 随机数生成器:伪随机数字
键盘和鼠标,块设备中断
/dev/random:仅从熵池返回随机数;随机数用尽,阻塞
/dev/urandom:从熵池返回随机数;随机数用尽,会利用软件生成伪随机数,非阻塞
openssl
- PKI:Public Key Infrastructure
CA
RA
CRL
证书存取库 - 建立私有CA:
OpenCA
openssl - 证书申请及签署步骤:
1、生成申请请求
2、RA核验
3、CA签署
4、获取证书
搭建私有CA需要用到关键配置文件/etc/pki/tls/openssl.cnf
34
35 ####################################################################
36 [ ca ]
37 default_ca = CA_default # The default ca section CA没有明确指定的情况下,使用CA_default
38
39 ####################################################################
40 [ CA_default ] CA_default中的各选项定义
41
42 dir = /etc/pki/CA # Where everything is kept CA的工作目录,由openssl软件包生成
43 certs = $dir/certs # Where the issued certs are kept 保存发布的证书列表
44 crl_dir = $dir/crl # Where the issued crl are kept 保存吊销的证书列表
45 database = $dir/index.txt # database index file. 证书的索引数据库,存放已颁发证书的相关信息,该文件默认不存在,需要手动创建,CA颁发证书后,会自动在该文件写入数据
46 #unique_subject = no # Set to 'no' to allow creation of
47 # several ctificates with same subject.
48 new_certs_dir = $dir/newcerts # default place for new certs. 存放新颁发的证书
49
50 certificate = $dir/cacert.pem # The CA certificate 保存根CA证书,即自签名证书
51 serial = $dir/serial # The current serial number 保存下一个要颁发证书的编号
52 crlnumber = $dir/crlnumber # the current crl number 保存下一个被吊销证书的编号
53 # must be commented out to leave a V1 CRL
54 crl = $dir/crl.pem # The current CRL 保存证书吊销列表
55 private_key = $dir/private/cakey.pem# The private key 保存私钥文件,且该文件必须被命名为cakey.pem
73 default_days = 365 # how long to certify for 证书默认有效期
74 default_crl_days= 30 # how long before next CRL 吊销证书列表每30天发布一次
75 default_md = sha256 # use SHA-256 by default 默认使用算法
76 preserve = no # keep passed DN ordering
81 policy = policy_match 策略默认使用policy_match
82
83 # For the CA policy
84 [ policy_match ]
85 countryName = match 国家
86 stateOrProvinceName = match 省
87 organizationName = match 公司名称
88 organizationalUnitName = optional 组织部门
89 commonName = supplied 证书用途(给哪个网站使用),必须提供
90 emailAddress = optional 邮箱
注意:policy_match策略要求国家、省、公司名称必须相同,其他项可以不同
92 # For the 'anything' policy
93 # At this point in time, you must list all acceptable 'object'
94 # types.
95 [ policy_anything ] policy_anything策略允许每项都不相同
96 countryName = optional
97 stateOrProvinceName = optional
98 localityName = optional
99 organizationName = optional
100 organizationalUnitName = optional
101 commonName = supplied 该选项必须提供
102 emailAddress = optional
注意:policy_anything策略各选项不必相同
创建CA和申请证书
- 创建私有CA:
openssl的配置文件:/etc/pki/tls/openssl.cnf
三种策略:匹配、支持和可选
匹配指要求申请填写的信息跟CA设置信息必须一致
支持指必须填写这项申请信息
可选指可有可无 - 1、创建所需要的文件
touch /etc/pki/CA/index.txt 生成证书索引数据库文件
echo 01 > /etc/pki/CA/serial 指定第一个颁发证书的序列号
注意:如果没有创建/etc/pki/CA/index.txt和/etc/pki/CA/serial文件,在颁发证书时会出错 - 2、 CA自签证书
生成私钥
cd /etc/pki/CA/
(umask 066; openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048)
生成自签名证书
openssl req -new -x509 –key /etc/pki/CA/private/cakey.pem -days 7300 -out /etc/pki/CA/cacert.pem
-new: 生成新证书签署请求
-x509: 专用于CA生成自签证书
-key: 生成请求时用到的私钥文件
-days n:证书的有效期限
-out /PATH/TO/SOMECERTFILE: 证书的保存路径
注意:创建时,要填写必要的信息:国家、省、公司名等 - 3、生成私钥以及证书申请
在需要使用证书的主机生成证书请求,给web服务器生成私钥
(umask 066; openssl genrsa -out /etc/pki/tls/private/test.key 2048)
生成证书申请文件
openssl req -new -key /etc/pki/tls/private/test.key -days 365 -out /etc/pki/tls/test.csr (-day 365可以省略不写,因为证书有效期由颁发机构指定)
注意:申请CA证书填写的内容中国家、省、公司名必须与服务器端自签名证书中的一致
把证书申请传递到服务器端
将证书请求文件传输给CA
scp /etc/pki/tls/test.csr x.x.x.x:/etc/pki/CA (x.x.x.x为服务器ip地址) - 4、CA签署证书,并将证书颁发给请求者
openssl ca -in /etc/pki/CA/test.csr –out /etc/pki/CA/certs/test.crt -days 365
注意:默认国家,省,公司名称三项必须和CA一致
查看证书中的信息:
openssl x509 -in /PATH/FROM/CERT_FILE -noout -text|issuer|subject|serial|dates
openssl ca -status SERIAL 查看指定编号的证书状态 - 5、吊销证书
在客户端获取要吊销的证书的serial
openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject
在CA上,根据客户提交的serial与subject信息,对比检验是否与index.txt文件中的信息一致,吊销证书:
openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem
指定第一个吊销证书的编号,注意:第一次更新证书吊销列表前,才需要执行
echo 01 > /etc/pki/CA/crlnumber
更新证书吊销列表
openssl ca -gencrl -out /etc/pki/CA/crl.pem
查看crl文件:
openssl crl -in /etc/pki/CA/crl.pem -noout -text
知识扩展:
如果再次申请CA证书,申请证书填写的信息(国家、省、公司名称)与根CA证书信息不一致,将出现以下错误信息:
The stateOrProvinceName field needed to be the same in the
CA certificate (xxxx) and the request (xxxx)
解决方法:
更改/etc/pki/tls/openssl.cnf配置文件
方法1:把policy_match策略更改为policy_anything,任意匹配
81 policy = policy_match
方法2:把国家、省、公司名称后的match更改为optional
84 [ policy_match ]
85 countryName = match
86 stateOrProvinceName = match
87 organizationName = match
88 organizationalUnitName = optional
89 commonName = supplied
90 emailAddress = optional