信息安全防護的目標

• 保密性 Confidentiality
• 完整性 Integrity
• 可用性 Usability
• 可控制性 Controlability
• 不可否認性 Non-repudiation

安全防護環節

• 物理安全：各種設備/主機、機房環境
• 系統安全：主機或設備的操作系統
• 應用安全：各種網絡服務、應用程序
• 網絡安全：對網絡訪問的控制、防火墻規則
• 數據安全：信息的備份與恢復、加密解密
• 管理安全：各種保障性的規范、流程、方法

常見的安全攻擊STRIDE

• Spoofing 假冒
• Tampering 篡改
• Repudiation 否認
• Information Disclosure 信息泄漏
• Denial of Service 拒絕服務
• Elevation of Privilege 提升權限

安全設計基本原則

• 使用成熟的安全系統
• 以小人之心度輸入數據
• 外部系統是不安全的
• 最小授權
• 減少外部接口
• 缺省使用安全模式
• 安全不是似是而非
• 從STRIDE思考
• 在入口處檢查
• 從管理上保護好你的系統

常用安全技術

• 認證
• 授權
• 審計
• 安全通信

加密算法和協議

• 對稱加密
• 公鑰加密
• 單向加密
• 認證協議

對稱加密算法

對稱加密：加密和解密使用同一個密鑰

特性：

• 加密、解密使用同一個密鑰，效率高
• 將原始數據分割成固定大小的塊，逐個進行加密

缺陷：

• 密鑰過多
• 密鑰分發
• 數據來源無法確認

常見對稱加密算法:

• DES：Data Encryption Standard，56bits
• 3DES：
• AES：Advanced (128, 192, 256bits)
• Blowfish，Twofish
• IDEA，RC6，CAST5

非對稱加密算法

非對稱加密算法介紹

非對稱加密：密鑰是成對出現

• 公鑰：public key，公開給所有人，主要給別人加密使用
• 私鑰：secret key，private key 自己留存，必須保證其私密性，用于自已加密簽名
• 特點：用公鑰加密數據，只能使用與之配對的私鑰解密；反之亦然

功能：

• 數據加密：適合加密較小數據,比如: 加密對稱密鑰
• 數字簽名：主要在于讓接收方確認發送方身份

缺點：

• 密鑰長,算法復雜
• 加密解密效率低下

常見算法：

• RSA：由 RSA 公司發明，是一個支持變長密鑰的公共密鑰算法，需要加密的文件塊的長度也是可變的,可實現加密和數字簽名
• DSA（Digital Signature Algorithm）：數字簽名算法，是一種標準的 DSS（數字簽名標準）
• ECC（Elliptic Curves Cryptography）：橢圓曲線密碼編碼學，比RSA加密算法使用更小的密鑰，提供相當的或更高等級的安全

非對稱加密實現加密

接收者
生成公鑰/密鑰對：P和S
公開公鑰P，保密密鑰S
發送者
使用接收者的公鑰來加密消息M
將P(M)發送給接收者
接收者
使用密鑰S來解密：M=S(P(M))

非對稱加密實現數字簽名

發送者
生成公鑰/密鑰對：P和S
公開公鑰P，保密密鑰S
使用密鑰S來加密消息M
發送給接收者S(M)
接收者
使用發送者的公鑰來解密M=P(S(M))

RSA和DSA

RSA：公鑰加密算法是1977年由Ron Rivest、Adi Shamirh和LenAdleman在（美國麻省理工學院）開發的，RSA取名來自開發他們三者的名字，后成立RSA數據安全有限公司。RSA是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的所有密碼攻擊，已被ISO推薦為公鑰數據加密標準。RSA算法基于一個十分簡單的數論事實：將兩個大素數相乘十分容易，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰

DSA (Digital Signature Algorithm)：1991年7月26日提交，并歸屬于David W. Kravitz前NSA員工，DSA是Schnorr和ElGamal簽名算法的變種，被美國NIST作為SS(DigitalSignature Standard)， DSA是基于整數有限域離散對數難題的，其安全性與RSA相比差不多。DSA只是一種算法，和RSA不同之處在于它不能用作加密和解密，也不能進行密鑰交換，只用于簽名,它比RSA要快很多

使用gpg實現對稱和非對稱加密

實現對稱加密

對稱加密file文件

gpg -c file

在另一臺主機上解密file

gpg -o file -d file.gpg 

實現公鑰加密

目標：在hostB主機上用公鑰加密，在hostA主機上解密 B —> A

在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 
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

單向哈希算法

哈希算法：也稱為散列算法，將任意數據縮小成固定大小的“指紋”，稱為digest，即摘要

特性：

• 任意長度輸入，固定長度輸出
• 若修改數據，指紋也會改變，且有雪崩效應，數據的一點微小改變，生成的指紋值變化非常大。
• 無法從指紋中重新生成數據，即不要逆，具有單向性

功能：數據完整性

常見算法

md5: 128bits、sha1: 160bits、sha224 、sha256、sha384、sha512

常用工具

• md5sum | sha1sum [ –check ] file
• openssl、gpg
• rpm -V

數字簽名

RPM 文件完整性
rpm –verify package_name (or -V)
rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat*
rpm –checksig pakage_file_name (or -K)

綜合應用多種加密算法

實現數據加密

實現數據加密，無法驗證數據完整性和來源

實現數字簽名

不加密數據，可以保證數據來源的可靠性、數據的完整性和一致性

綜合加密和簽名

即實現數據加密，又可以保證數據來源的可靠性、數據的完整性和一致性

方法1：Pb{Sa[hash(data)]+data}

方法2：對稱key{Sa[hash(data)]+data}+Pb(對稱key)

密碼交換

密鑰交換：IKE（ Internet Key Exchange ）

• 公鑰加密：
• DH (Deffie-Hellman)：生成會話密鑰，由惠特菲爾德·迪菲（Bailey Whitfield Diffie）和馬丁·赫爾曼（Martin Edward Hellman）在1976年發表

  參看：https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

DH 實現過程：

A: g,p 協商生成公開的整數g, 大素數p
B: g,p
A:生成隱私數據 :a (a<p )，計算得出 g^a%p，發送給B
B:生成隱私數據 :b,計算得出 g^b%p，發送給A
A:計算得出 [(g^b%p)^a] %p = g^ab%p，生成為密鑰
B:計算得出 [(g^a%p)^b] %p = g^ab%p，生成為密鑰

CA和證書

中間人攻擊

Man-in-the-middle，簡稱為 MITM，中間人

CA和證書

PKI：Public Key Infrastructure 公共密鑰加密體系
簽證機構：CA（Certificate Authority）
注冊機構：RA
證書吊銷列表：CRL
證書存取庫：

X.509：定義了證書的結構以及認證協議標準

• 版本號
• 序列號
• 簽名算法
• 頒發者
• 有效期限
• 主體名稱

證書類型：

• 證書授權機構的證書
• 服務器證書
• 用戶證書

獲取證書兩種方法：

• 自簽名的證書： 自已簽發自己的公鑰
• 使用證書授權機構：
  • 生成證書請求（csr）
  • 將證書請求csr發送給CA
  • CA簽名頒發證書

安全協議 SSL/TLS

TLS 介紹

SSL：Secure Socket Layer，TLS: Transport Layer Security

1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布

1995：SSL 2.0 Netscape 開發

1996：SSL 3.0

1999：TLS 1.0

2006：TLS 1.1 IETF(Internet工程任務組) RFC 4346，從2020年3月起，停止支持TLS 1.1及TLS 1.0版本安全協議，谷歌（Chrome）、Mozilla（Firefox）、微軟（IE和Edge） 、蘋果（Safari） 都會發布新版瀏覽器執行這個策略

2008：TLS 1.2 當前主要使用

2018：TLS 1.3

功能：

• 機密性
• 認證
• 完整性
• 重放保護

SSL/TLS組成

• Handshake協議：包括協商安全參數和密碼套件、服務器身份認證（客戶端身份認證可選）、密鑰交換
• ChangeCipherSpec 協議：一條消息表明握手協議已經完成
• Alert 協議：對握手協議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續，只是會給出錯誤警告
• Record 協議：包括對消息的分段、壓縮、消息認證和完整性保護、加密等

TLS實現過程

實現分為握手階段和應用階段

• 握手階段(協商階段):客戶端和服務器端認證對方身份（依賴于PKI體系，利用數字證書進行身份認證），并協商通信中使用的安全參數、密碼套件以及主密鑰。后續通信使用的所有密鑰都是通過MasterSecret生成
• 應用階段:在握手階段完成后進入，在應用階段通信雙方使用握手階段協商好的密鑰進行安全通信

目前密鑰交換 + 簽名有三種主流選擇：

• RSA 密鑰交換、RSA 數字簽名
• ECDHE 密鑰交換、RSA 數字簽名
• ECDHE 密鑰交換、ECDSA 數字簽名

實現方式1

RSA 密鑰交換、RSA 數字簽名

1. Visitor給出協議版本號、一個客戶端隨機數（Client random），以及客戶端支持的加密方法
2. Server確認雙方使用的加密方法，以及一個服務器生成的隨機數（Server random）
3. Server發送數字證書給Visitor
4. Visitor確認數字證書有效（查看證書狀態且查詢證書吊銷列表），并使用信任的CA的公鑰解密數字證書獲得Server的公鑰，然后生成一個新的46字節隨機數（稱為預備主密鑰Pre-master secret），并使用Server的公鑰加密預備主密鑰發給Server
5. Server使用自己的私鑰，解密Visitor發來的預備主密鑰
6. Visitor和Server雙方都具有了(客戶端隨機數+服務端隨機數+預備主密鑰)，它們兩者都根據約定的加密方法，使用這三個隨機數生成對稱密鑰——主密鑰（也稱為對話密鑰session key），用來加密后續的對話過程
7. 在雙方驗證完session key的有效性之后，SSL握手機制就算結束了。之后所有的數據只需要使用“對話密鑰”(此密鑰并不是的session key，而是由其通過計算得到)加密即可，不再需要多余的加密機制

注意：
1.在SSL握手機制中，需要三個隨機數（客戶端隨機數+服務端隨機數+預備主密鑰）
2.至始至終客戶端和服務端只有一次非對稱加密動作——客戶端使用證書中獲得的服務端公鑰加密預備主密鑰。
3.上述SSL握手機制的前提單向驗證，無需驗證客戶端，如果需要驗證客戶端則可能需要客戶端的證書或客戶端提供簽名等。
4.Server和Visitor通信，Server把數字證書發給Visitor，最關鍵的一點是Visitor要保證證書的有效性，通過查看證書狀態并去CA的吊銷列表查看Server的證書是否被吊銷。只有Server的證書可用了，才保證了第一環節的安全性
5.RSA 密鑰交換有一個很大的問題：沒有前向安全性Forward Secrecy。這意味著攻擊者可以把監聽到的加密流量先存起來，后續一旦拿到了私鑰，之前所有流量都可以成功解密

實現方式2

目前大部分 HTTPS 流量用的都是 ECDHE 密鑰交換。ECDHE 是使用橢圓曲線（ECC）的 DH（Diffie-Hellman）算法

前圖中的 Server DH Parameter 是用證書私鑰簽名的，客戶端使用證書公鑰就可以驗證服務端合法性。相比 RSA 密鑰交換，DH 由傳遞 Premaster Scret 變成了傳遞 DH 算法所需的 Parameter，然后雙方各自算出 Premaster Secret

對于這種情況，由于 Premaster Secret 無需交換，中間人就算有私鑰也無法獲得 Premaster Secret 和 Master Secret。當然，使用 ECDHE 后，雖然中間人拿到私鑰也無法解密之前的流量，但可以實施 MITM 攻擊來解密之后的流量，所以私鑰還是要保管好。

相比 RSA 既可以用于密鑰交換，又可以用于數字簽名；ECC 這邊就分得比較清楚了：ECDHE 用于密鑰交換，ECDSA 用于數字簽名

HTTPS

HTTPS 協議：就是“HTTP 協議”和“SSL/TLS 協議”的組合。HTTP over SSL”或“HTTP over TLS”，對http協議的文本數據進行加密處理后，成為二進制形式傳輸

HTTPS結構

HTTPS工作的簡化過程

1. 客戶端發起HTTPS請求
   用戶在瀏覽器里輸入一個https網址，然后連接到服務器的443端口
2. 服務端的配置
   采用HTTPS協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰
3. 傳送服務器的證書給客戶端
   證書里其實就是公鑰，并且還包含了很多信息，如證書的頒發機構，過期時間等等
4. 客戶端解析驗證服務器證書
   這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨機值。然后用證書中公鑰對該隨機值進行非對稱加密
5. 客戶端將加密信息傳送服務器
   這部分傳送的是用證書加密后的隨機值，目的就是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了
6. 服務端解密信息
   服務端將客戶端發送過來的加密信息用服務器私鑰解密后，得到了客戶端傳過來的隨機值
7. 服務器加密信息并發送信息
   服務器將數據利用隨機值進行對稱加密,再發送給客戶端
8. 客戶端接收并解密信息
   客戶端用之前生成的隨機值解密服務段傳過來的數據，于是獲取了解密后的內容

本文鏈接：http://www.thecarconnectin.com/33949.html