您好,登錄后才能下訂單哦!
在現(xiàn)代互聯(lián)網(wǎng)中,安全是一個不容忽視的問題,說到安全就不得不涉及到加密,解密?,F(xiàn)在只要我們數(shù)據(jù)在互聯(lián)網(wǎng)上傳播就避免不了一些有惡意企圖的人窺探,所以在網(wǎng)絡中傳播數(shù)據(jù)時首先要考慮幾個因素,對方的身份,數(shù)據(jù)的完整性,數(shù)據(jù)的私密性。
常用的密碼算法:對稱加密,公鑰加密,單向加密。
對稱加密是加密和解密使用同一個秘鑰,將原始數(shù)據(jù)分塊進行加密。優(yōu)點是加密速度快,常用于加密數(shù)據(jù)比較大的時候。其缺點是秘鑰無法安全的送到對方。如果密碼遺漏數(shù)據(jù)安全不復存在。常用的加密算法:DES,3DES,AES,Blowfish,Twofish,IDEA,RC6,CAST5。
使用工具:openssl
舉例:把qq.txt文件加密。
openssl enc -a -salt -des3 -in /tmp/qq.txt -out /tmp/qqs.txt 然后輸入2次自己定義的密碼。
-a : 表示已base64的方式加密。
-des3:加密算法。
此時查看加密后的qqs.txt
解密:openssl enc -d -salt -des3 -a -in /tmp/qqs.txt -out /tmp/qqj.txt
-d:解密。
在例子中可見,對稱加密和解密使用的同樣的方式,而且如果在網(wǎng)絡傳輸中傳輸密碼或密碼泄露數(shù)據(jù)也是不安全的。
單向加密:
單向加密即加密運算后的數(shù)據(jù)是不可逆的,不能反向運算出原數(shù)據(jù)。一般通過散列函數(shù)計算,散列函數(shù)的主要任務用于計算數(shù)據(jù)的完整性。常用算法有:MD5,SHA-1,SHA256,SHA384,SHA512。其特點是輸入一樣輸出也是一樣。如果輸入發(fā)生任何改變,結果將引起巨大改變。無法通過輸出結果還原原來的數(shù)據(jù),無論輸入多大,輸出結果都是相同的大小。
舉例:使用MD5算法計算qq.txt的結果。openssl dgst -md5 qq.txt
[root@localhost tmp]# openssl dgst -md5 qq.txt MD5(qq.txt)= cd7257236da80701dd11ce383644e213 [root@localhost tmp]# vim qq.txt 151515252:13523452345 455667678:45767687877 567787881:13456566767 667788931:15667676833 234457890:15899865663 567787881:13778798888 667788931:15678789904 234457890:15467689909 567791246:18755653256 234457890:15467685229 567791246:18758944576 d
"qq.txt" 12L, 244C written [root@localhost tmp]# openssl dgst -md5 qq.txt MD5(qq.txt)= c8fcbdb073a0381a8d2d9542dfc64800 [root@localhost tmp]# |
由此可見,在文本中末尾添加了一個字符d,其結果與上一次大不相同。由于具備不可逆的特性所以常用于驗證文件是否發(fā)生過改變。而輸出的結果我們通常稱之為數(shù)據(jù)的指紋,或特征碼。
公鑰加密:
公鑰加密也稱為非對稱加密,與對稱加密不同的是它有兩個秘鑰,即公鑰和私鑰,這兩個秘鑰成對出現(xiàn)如果使用公鑰加密數(shù)據(jù)解密必須用私鑰。用私鑰加密的數(shù)據(jù)解密要用其公鑰。因為它加密和解密使用不同的秘鑰所以稱之為非對稱加密。常結合其他加密方式組合使用。
生成自己的秘鑰對:
在當前目錄中生成一個2048位的秘鑰保存到mykey中,注意默認生成權限出屬主外賬戶有讀權限,要禁止其他用戶讀取需修改權限或者直接使用:(umask 077;openssl genrsa 2048 >mykey)
[root@localhost tmp]# openssl genrsa 2048 >mykey Generating RSA private key, 2048 bit long modulus .................+++ ..............................+++ e is 65537 (0x10001) [root@localhost tmp]# ll -rw-r--r-- 1 root root 1679 Sep 26 03:51 mykey -rw-r--r-- 1 root root 242 Sep 26 02:54 qqj.txt -rw-r--r-- 1 root root 358 Sep 26 02:49 qqs.txt -rw-r--r-- 1 root root 244 Sep 26 03:31 qq.txt |
提取公鑰:
[root@localhost tmp]# openssl rsa -in /tmp/mykey -pubout writing RSA key -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1CZOG8YAJ81strW7T9Sx cdsdD9tc0wNk5Qv7qE2PyNAthCuQdernyWYbf0on6uOGVfiHu0djLc9mfbDlXV2q Bu5WDS8Kh5RCFbTjeA35h+YGni16foQxa/U1QjijBK9Ju0BNQt/fblRsbjHR3W3g 0eUd5gJBgFf+p3W9FjR5S063ACIprVZF0u1Eu5lrOkKdtcHAXqSGQje70DCxJA3y iMtcTxSwBl3YRTuu37GMYot5KVBKzxAfcs7xjB34qxremBZlrLB3Wv8mG1bFf3GH siQjPtQ3gSig5spovPVccc5w4LglYE94OOa++hjf0btbBAqB9hET928cWZSGOuH+ 9wIDAQAB -----END PUBLIC KEY----- [root@localhost tmp]# |
以上步驟完成公鑰和私鑰已創(chuàng)建完成。并且私鑰一定要保證其安全性。
以上三種加密方式各有特點,但也有各自的缺陷。如果單獨用于網(wǎng)絡數(shù)據(jù)加密仍然不可靠。但把他們組合在一起使用安全就有保障了。
首先發(fā)送方:
1、 把要發(fā)送的原文數(shù)據(jù)使用單向加密抽取出原文的特征碼,用來保證數(shù)據(jù)的完整性。
2、 發(fā)送方使用非對稱加密,即用自己的私鑰把原文的特征碼加密,加到原文后面。這樣一來就保證身份,接收方有發(fā)送方的公鑰收到數(shù)據(jù)后能正常用對方的公鑰解密得到特征碼即證明了數(shù)據(jù)發(fā)送方的身份。
3、 發(fā)送方再選擇一個密碼,用對稱加密方式對原文和加密過的特征碼一起再次進行加密。因為對稱加密方式比較快如果數(shù)據(jù)過大也不太影響。
4、 發(fā)送方把選擇的密碼用接收方的公鑰加密后一并把數(shù)據(jù)發(fā)給接收方。
接收方:
1、 接收方收到數(shù)據(jù)后首先使用自己的私鑰得到了一個密碼就是發(fā)送方打包的原數(shù)據(jù)和特征碼。
2、 使用得到的密碼打開發(fā)送方打包加密的原數(shù)據(jù)和特征碼。此時得到了原數(shù)據(jù),只有了原數(shù)據(jù)并不能確定數(shù)據(jù)沒有被修改或替換過。此時要驗證數(shù)據(jù)的完整性
3、 接收方用發(fā)送方的公鑰解密加密過的特征碼,而后得到了原數(shù)據(jù)的特征碼。
4、 接收方用通樣的方式對原數(shù)據(jù)計算特征碼把得到的特征碼和解密后的特征碼進行比對如果一致說明數(shù)據(jù)沒有被修改過。如果不一致說明此信息不可靠。
總結整個過程:
在過程中使用了三種加密方式組合,雙方通過非對稱加密驗證了彼此的身份,因為發(fā)送方的數(shù)據(jù)密碼使用了接收方的公鑰加密了,這個數(shù)據(jù)只能是接收方的私鑰才能解密,其他人得到了這些數(shù)據(jù)也是沒有用處。使用對稱加密對原數(shù)據(jù)進行加密使得原文得到加密。又通過單向加密的方式進行了特征碼的比對驗證了信息的可靠性。
下面用一張圖表示過程:
在以上的過程當中接收方和發(fā)送方都事前有對方的公鑰且互相信任,但在互聯(lián)網(wǎng)當中我們又怎么保證對方公鑰的可信度,如果對方是一個冒名頂替的呢我們將無從獲知,所以我們需要一個可信的機構來保證,就好比我們生活當中一個人說他是張三住在甲街1號,我怎么知道他說的是真是假呢,我去派出所查一下,派出所說確實有個人叫張三住在甲街1號。那么我就認為他就是張三否則就不是。而在互聯(lián)網(wǎng)中這個“派出所”就是CA,它負責給互聯(lián)網(wǎng)上的主機簽發(fā)證書。而如果你想在互聯(lián)網(wǎng)上得到“信任”就要先到CA那里注冊,CA核實你的身份信息然后提取信息的特征碼用CA自己的私鑰加密后發(fā)給你而這就是你的數(shù)字簽名。
有了簽名之后當我們需要與一個主機通訊的時候對方會發(fā)給我它的證書,這時我首先去用CA的公鑰解密證書,如果能夠解密說明證書是CA給頒發(fā)的,CA已經核實過他的身份和信息了我們認為對方是可靠的,但我們需要進一步證明證書是否在有效期內和是否是已經吊銷的證書,這個查詢就需要到CA那里查詢。當整個確認過程沒有問題之后通信才真正的開始。而以上的整個加密解密過程和CA的這種驗證機制行程了一個新的技術規(guī)范就是:PKI(Public.Key.Infrastructure)。
CA證書的這種機制不是一定要應用于大型互聯(lián)網(wǎng)中在自己的私有范圍內也可以使用,其中使用的工具就是openssl。
建立私有CA:
1、 生成秘鑰:
(umask077; openssl genrsa –out /etc/pki/CA/private/cakey.pem 2048)
[root@localhost private]# (umask 077; openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048) Generating RSA private key, 2048 bit long modulus ...............+++ ................+++ e is 65537 (0x10001) [root@localhost private]# |
2、 簽署請求:
[root@localhost private]# openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 365 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:CN State or Province Name (full name) []:PEK Locality Name (eg, city) [Default City]:PEK Organization Name (eg, company) [Default Company Ltd]:FF Organizational Unit Name (eg, section) []:FF Common Name (eg, your name or your server's hostname) []:ops Email Address []:admin@admin.com [root@localhost private]# ls /etc/pki/CA/cacert.pem /etc/pki/CA/cacert.pem [root@localhost private]# ls /etc/pki/CA/ cacert.pem certs crl newcerts private [root@localhost private]# |
使用命令:openssl req-new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem –days365,發(fā)起證書簽署請求,然后會提示你填寫一些信息。
req:生成證書簽署請求;-news:新請求;-key /path/to/keyfile:指定私鑰文件; -x509:生成自簽署證書; -days 365:有效天數(shù),可自定義。
然后在CA目錄下新建2個文件,index.txt 和serial
然后:~]# echo 00 > seria
3、 簽署證書:
簽署請求生成的方法在文中提到過。不在重復說明,簽署證書命令:
openssl ca -in /tmp/mykey.csr -out /tmp/ff.com.crt -days 365
-in:指明請求文件位置
-out:指明輸出文件名和位置。
-days:指明簽署有效期限。
[root@localhost CA]# openssl ca -in /tmp/mykey.csr -out /tmp/ff.com.crt -days 365 Using configuration from /etc/pki/tls/openssl.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 0 (0x0) Validity Not Before: Sep 26 12:22:03 2015 GMT Not After : Sep 25 12:22:03 2016 GMT Subject: countryName = CN stateOrProvinceName = PEK organizationName = FF organizationalUnitName = OPS commonName = OPS emailAddress = admin@ff.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 12:2C:F0:DF:C1:99:08:88:73:BA:04:8E:C4:2F:26:20:52:F5:A2:13 X509v3 Authority Key Identifier: keyid:84:C4:2E:4A:ED:A6:9D:26:A1:80:BE:D2:47:7F:CC:D9:85:97:4D:19
Certificate is to be certified until Sep 25 12:22:03 2016 GMT (365 days) Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated [root@localhost CA]# [root@localhost CA]# cat serial 01 [root@localhost CA]# cat index.txt V 160925122203Z 00 unknown /C=CN/ST=PEK/O=FF/OU=OPS/CN=OPS/emailAddress=admin@ff.com [root@localhost CA] |
上圖中看到在index.txt中.生成了簽署記錄.其他主機簽署是同樣的方式,只不過需要把請求通過一些途徑發(fā)送給CA。
吊銷證書:當有主機秘鑰丟失或泄露為保證安全需要向CA申請吊銷證書。
1、 獲取要吊銷證書的序號和信息。
[root@localhost CA]# openssl x509 -in /tmp/ff.com.crt -noout -serial -subject serial=00 subject= /C=CN/ST=PEK/O=FF/OU=OPS/CN=OPS/emailAddress=admin@ff.com [root@localhost CA]# |
2、 核實要吊銷證書是否與申請吊銷主機提供的信息是否一致。
3、 吊銷證書:openssl ca -revoke /etc/pki/CA/newcerts/00.pem
如果是第一次吊銷需生成吊銷證書的編號: echo 01 > /etc/pki/CA/crlnumber
4、 更新吊銷證書列表:openssl ca -gencrl -out ff.com.crl
查看crl文件:openssl crl -in /path/to/crl_FILE.crl -noout -text
[root@localhost crl]# openssl crl -in ff.com.crl -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=CN/ST=PEK/L=PEK/O=FF/OU=FF/CN=ops/emailAddress=admin@admin.com Last Update: Sep 26 12:45:50 2015 GMT Next Update: Oct 26 12:45:50 2015 GMT CRL extensions: X509v3 CRL Number: 1 Revoked Certificates: Serial Number: 00 Revocation Date: Sep 26 12:40:47 2015 GMT Signature Algorithm: sha1WithRSAEncryption b5:f4:9c:ec:3d:4a:e4:d1:1b:48:d4:a0:5e:06:4f:a0:ab:e6: 76:de:62:f6:88:8e:cc:ec:b9:de:39:db:8c:a0:00:3e:57:41: 73:09:90:e9:64:4c:0a:01:70:0b:ac:43:f2:28:0a:1a:77:c9: b2:20:ef:30:d6:3d:5b:7b:a0:5a:5d:dc:1a:95:63:4b:e8:11: e9:f6:53:8b:42:83:cb:34:cc:cc:25:94:de:f9:54:77:a4:1f: 6a:12:27:77:e2:fc:48:3b:56:58:08:f2:47:0c:f2:4d:52:ed: 0e:ba:e6:76:47:d5:d5:6f:de:44:5d:73:3d:ff:14:13:b1:d0: aa:da:ee:6e:4d:84:d7:34:e9:4f:0f:fe:aa:9f:da:6e:a9:bd: 2b:aa:3e:82:2b:91:f4:37:bd:38:08:99:94:95:0b:98:3b:93: 81:bf:cc:6a:80:31:f5:73:4f:45:e3:5f:53:25:a3:d9:95:03: c7:27:e8:44:c1:97:9d:cb:8d:26:9d:69:d3:0d:ba:6d:a8:1b: 6f:47:e9:fb:9e:ad:9c:f5:e9:9c:b0:50:be:e2:35:44:2b:c5: 6b:c6:36:3d:52:e5:d1:5a:6c:56:13:57:6f:67:e5:5b:ba:1d: 5c:d4:5b:81:9b:e7:c2:9e:99:c7:7b:ea:48:ff:3c:70:5d:96: 50:20:18:1a [root@localhost crl]# |
crt證書文件可以配置到http服務器當中,這樣就可以用https的訪問站點,實現(xiàn)交換數(shù)據(jù)的全。
至此私有CA搭建和證書簽署已經完成。此文只為個人知識總結便于以后查閱用。
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經查實,將立刻刪除涉嫌侵權內容。