TCP/IP 筆記 - 安全

安全：可擴展身份認證協議、IP安全協議、傳輸層安全、DNS安全、域名密鑰識別郵件

任何由用戶或以用戶帳號執行卻違背了用戶自己意願的軟件被稱爲惡意軟件

網絡安全是一門十分普遍及有深度的學識，而本書旨在瞭解TCP/IP協議族知識，因此書中只介紹了一些TCP/IP所使用的部分安全方案。而且對安全這塊我也沒多少深刻的研究，也就基於書本內容作些知識摘抄以供瞭解和學習。

信息安全基礎

從信息安全的角度看，不管是否在計算機網絡中，信息都該具備一些屬性：

　　1. 機密性，信息只能爲其指定的用戶知曉。

　　2. 完整性，信息在傳輸完成以前不可以經過未受權的方式修改。

　　3. 可用性，在須要的使用信息是可用的。

　　4. 可認證性，一個通過身份認證的組織或個體是不可以被其餘個體假冒的。

　　5. 不可抵賴性，一個個體作出的任何行爲都可以在此以後獲得證明。

　　6. 可審計性，一些可信的日誌或說明可以面試信息使用的過程。

前三者是重要的核心屬性，又稱'CIA三元組'。

根據[VK83]，攻擊一般被分爲被動和主動兩類。被動攻擊通常會監視或竊聽網絡流量的內容，若是不加以控制，它將會致使信息未經受權就發佈出去，這破壞了信息的機密性。主動攻擊通常會篡改信息或使其拒絕服務，這破壞了信息的完整性和可用性。

被動攻擊：

　　竊聽(機密性)

　　流量分析(機密性)

主動攻擊：

　　消息流篡改(可認證性，完整性)

　　拒絕服務DoS(可用性)

　　僞造機構(可認證性)

經過加密機制，便可知足以上兩種攻擊的防護需求，經過加密後的數據不容易泄露信息內容、不容易破壞其完整性、也更安全的保障了可認證性。

基礎的加密和相關知識

傳統的基礎加密主要用於保護信息的機密性，但其餘屬性如完整性和可認證性也可以藉助加密以及相關的數學技術達到。下面的圖說明了兩個重要的加密算法：對稱密鑰和公開(非對稱)密鑰是如何工做的。

在對稱密碼系統中，因爲加解密的算法相同，它們的密鑰也是相同的。

在非對稱密碼系統中，每個個體都擁有一對密鑰，包括一個公鑰和一個私鑰。公鑰是公開的，任何但願向這對私鑰全部者發送消息的人都可以得到。公鑰和私鑰有數學上的關聯，它們都是密鑰生成算法的輸出結果。若是不知道對稱密碼系統中的對稱密鑰或非對稱密碼系統中的私鑰，任何第三方截獲密文後都沒法生成相應的明文。

對稱密碼算法一般被分爲分組密碼(或稱塊密碼)與流密碼兩類。分組密碼每次只對固定數目的比特塊進行操做，而流密碼將提供的大量比特做爲輸入而且會持續的運行下去。多年來流行的對稱密碼算法是數據加密標準(DES，是一種分組密碼，使用64比特的數據塊與56位的密鑰)。該算法最終被認爲不安全，後期採用3重DES利用兩個或三個不一樣密鑰對每個數據塊進行三次DES加密。但不管DES仍是3DES，如今都逐漸被高級加密標準(AES)所取代[FIPS197]。AES針對不一樣版本所提供的密鑰長度，如128位、192位、256位，因而就有了AES-12八、AES-19二、AES-256。

如上圖，非對稱密碼算法存在一個問題：發送者使用接收者的公鑰進行消息加密後發給接收者，那麼只能擁有接收者私鑰纔可以對消息進行解密，然而這個消息不能保證是真實可靠的(由於任何人都可以發送這條消息給接收者)。因而基於非對稱加密的公鑰-密鑰的關聯性，非對稱密碼系統提供了另外一項功能：對發送者進行認證。
該功能由將公鑰加密和私鑰解密反向操做而實現，以下圖：

流行的公鑰密碼算法如RSA，在其初始化階段，須要生成兩個大素數p和q。這項工做首先須要隨機地生成數值較大的奇數，後檢驗這些數是否爲素數，直到找到兩個大素數爲止。兩個素數的乘積 n = pq 被稱爲模。n，p，q的長度通常用比特來衡量。推薦n採用2048比特的長度，但一般狀況下n爲1024比特，p和q的長度爲512比特。

根據RSA算法，n的構建方法爲：

    Φ(n) = (q - 1)(p - 1)

Φ(n)的值表示n的歐拉數，是那些比n小且與n互質的正整數的個數。

根據Φ(n)的定義，選擇RSA的公鑰指數(稱爲e，表示加密)，並按照關係式d = e(^-1)(modΦ(n))獲得私鑰指數(稱爲d，表示解密)做爲乘法逆元素。爲獲取密文c，須要使用公式m = m(^e)(mod n)對明文m進行計算；反之則須要公式m = c(^d)(mod n)進行解密。一個RSA的公鑰包含公鑰指數e和模n，對應的私有則包含私鑰指數d和模n。若是爲了對一條消息m進行RSA數字簽名，能夠經過公式s = m(^d)(mod n)計算s的數值做爲m的簽名。任何接收到s的人可以使用公有元素e與公式m = s(^e)(mod n)進行檢驗，這樣就可以驗證生成數值s的是RSA的私有值d。RSA的安全性是基於對大數分解因數的困難性。

Diffie-Hellman-Merkle 密鑰協商協議(DH)提供了一種解決"通訊雙方如何在竊聽者不知情的狀況下完成共同密鑰協商"的計算方法，DH技術已用於許多與互聯網相關的安全協議[RFC2631]。

DH的工做以下描述：

　　1. 假設全部人都有相同的特徵，而且知道兩個證書p和q。p是一個(大)素數，g是模p的原根(g<p)。

　　2. 基於1，集合Z(_p) = {1,...,p-1}中的每個整數都可以經過不斷地增長g來生成，也就是說對於任意一個證書n，一定存在倍數k使式子g(^k) ≡ n(mod p)成立。在給定g、n與p的狀況下尋找合適的k值被認爲是一件困難的事(離散對數問題)，在給定g、k與p的狀況下找出n是容易的。

創建一個共享的安全密鑰過程以下(A和B之間)：

　　1. A選擇一個祕密的隨機數a，並按照公式 A = g(^a)(mod p)計算出A的值，而後將這個值發送給B；B選擇一個祕密的隨機數b，並按照公式 B = g(^b)(mod p)計算出B的值，而後將這個值發送給A。

　　2. A將按照如下公式計算K值：K = B(^a)(mod p) = g(^ba)(mod p)；B將按照如下公式計算K值：K = A(^b)(mod p) = g(^ab)(mod p)。

因爲g(^ab)和g(^ba)是相等的，因此A和B都能得到協商密鑰K。第三方竊聽者只能獲取g、p、A、B，所以在解決離散對數問題以前將沒法獲取密鑰K。

在通訊雙方須要交換多條消息的場景中，一般會創建一個短時間的會話密鑰來進行對稱加密。會話密鑰通常由密鑰派生函數(KDF)根據一些輸入而生成的隨機數，這些輸入多是一個主密鑰或以前的會話密鑰。若是一個密鑰被破解，那麼由該密鑰加密的任何數據都會被破解，然而在一個持續的通訊會話期間，每每會屢次更改密鑰。若是一種方案可以保證即便有一個會話密鑰被破解而由其餘密鑰加密的後續通訊過程仍然安全，那麼就稱該方案是徹底正向保密(PFS)的。一般狀況下可以提供徹底正向保密的方案須要額外的密鑰交換與認證過程，這樣就引入了新的開銷。

加密隨機數是在密碼協議中只使用一次的數值(又稱臨時密鑰)。經常使用於認證協議，選擇一個隨機數或者僞隨機數來保障時新性(時新性要求選取最新發生的消息或操做)。例如，在一個challenge-response協議中，服務器會爲請求的客戶端提供一個臨時密鑰，而客戶端須要在指定時間內發送認證資料與臨時密鑰的副本做爲響應。因爲重放到服務器上的舊的認證交換信息不會包含正確的臨時密鑰數值，所以這種方法可以避免重放攻擊。

混淆值是一個用於加密文本中的隨機數或者僞隨機數，可用於防護對密文的蠻力攻擊(反覆地猜想密碼、口令、密鑰或等效的祕密中並驗證其是否正確)。

加密散列函數，相似於部分加密算法，用於作傳輸數據完整性的保障及預防對消息的篡改攻擊。當一條消息M做爲輸入時，加密散列函數的輸出H被稱爲這條消息的摘要或指紋H(M)。它不只易於計算，還具備如下特徵：

　　1. 原像不可計算性，在給定摘要H(M)而未知消息M的狀況下，難以得出消息M的值。

　　2. 原像不相同性，給定消息M1的摘要H(M1)，找出消息M2(M1 ≠ M2)使它的摘要與M1的摘要相等(H(M1) = H(M2))是十分困難的。

　　3. 抗碰撞性，找出一堆摘要相同(H(M1) = H(M2))而自身不一樣的消息M一、M2(M1 ≠ M2)是十分困難的。

目前最通用的兩個加密散列算法是生成128位摘要的消息摘要算法(MD5)和生成160位摘要的安全散列算法(SHA-1)。SHA-2基於一系列SHA函數，可以生成長度224，256，384，512位的摘要。

消息認證碼(簡稱MAC或MIC)，通常基於有密鑰的加密散列函數，用於保障消息的完整性和防止各類僞造。這些函數相似於消息摘要算法，但須要一個私鑰來驗證消息的完整性，甚至也可能用於驗證消息的發送者。給定有密鑰的散列函數H(M,K)，M爲輸入的消息，K是密鑰，抵禦"選擇性僞造"意味着地方在不知道密鑰K的狀況下對指定的消息M生成散列值H(M,K)是很是困難的。消息認證碼因爲不止有一方知道對應的密鑰，因此並不能爲不能否認性提供堅實基礎。

一個標準的使用加密散列函數的消息認證碼被稱爲基於有密鑰散列的消息認證碼(HMAC)，下面的公式定義了使用密鑰K對消息M用H進行散列的方法(HMAC-H)，它造成t字節的HMAC：

    HMAC-H(K,M)(^t) = Λ(_t)(H((K ⊕ opad) || H((K ⊕ ipad) || M)))

opad(外填充)是一個將數值0x5C重複|K|次的數組，ipad(內填充)是講數值0x36重複|K|次的數組。⊕是向量的異或運算符，||是鏈接運算符，Λ(_t)表示取消息M最左邊的t字節。其中的將一個散列函數做用於另外一個散列函數的結構可以抵禦所謂的擴展攻擊，內填充與外填充的數值並不重要，但生成的2次密鑰K1與K2須要有較大的區別。

隨着消息認證碼多年以來的發展，一些其餘形式的消息認證碼已經被標準化，好比基於密碼的消息認證碼CMAC、GMAC。這些新標準不使用HMAC的加密散列函數，而是使用分組密碼，如AES。根據[RFC4493]描述，CMAC使用的是AES-128算法。GMAC則採用了AES算髮的一種特殊模式，稱爲Galois/計數器模式，它仍然使用一個有密鑰的散列函數(GHASH，並非一個加密散列函數)。

證書相關知識

一種被稱爲"信任網絡"的模型：經過一些當前用戶(稱爲代言人)來作代言的方式以證實一個證書(身份-公鑰對)的可靠性。一個代言人會對一個證書進行簽名，而後將其發佈出去，隨着時間推移，若是一個證書有愈來愈多的代言人，那麼它就越可靠。該模型是分散的、沒有中心的權威機構，所以它具備必定的"草根"性。"信任網絡"的優缺點顯而易見，有點是其不存在中心的權威機構，模型不會由於單點失效而奔潰；缺點是新加入者須要經歷至關長的時間才能使本身的密鑰獲得必定數量用戶的代言。

一種更常見的方法是依靠中心化的機構，其中包括對公鑰基礎設施(PKI)的使用，PKI負責提供建立、吊銷、分發以及更新密鑰對證書的服務。它須要一些證書頒發機構(CA)才能運行，CA是用於管理與認證一些個體與它們的公鑰間的綁定關係的實體。

ITU-T X.509 是公鑰證書的格式標準[RFC5280]，常見的的包括DER、PEM、PKCS#七、PKCS#12。

可用 openssl 命令來查看網站證書信息:

    openssl x509 -in xxx.pem -text

給出結構大體：

Certificate:  解碼後的證書信息
    Data:  元數據
        Version:  版本，特定的證書類型
        Serial Number:  特定證書的序列號
    Signature Algorithm:  簽名算法
        Issuer:  發行者，擁有如下特殊子域：C(國家)、L(地區或城市)、O(組織)、OU(組織單元)、ST(州或省)、CN(通用名稱)
        Validity:  有效時間
            Not Brfore:  起始時間
            Not After:  結束時間
        Subject:  主題，標識與當前證書相關的實體
        Subject Public Key Info:  主題公鑰信息，標識公鑰的擁有者
            Public Key Algorithm:  公鑰算法
                Public-Key:  公鑰
                Modulus:  模
                    ...
                Exponent:  指數
    Signature Algorithm:  簽名算法
        ...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

# ... 根據字段決定值類型，表明密鑰/簽名等結果內容

在證書撤銷的過程當中，須要考慮一些問題'如何撤銷證書？'、'如何讓依賴方知道他們所依賴的證書再也不可信？'。

爲了驗證某個證書，須要創建一條驗證(或認證)路徑，這條路徑應當是一個已被驗證過的證書集合，一般會包含依賴方已經的信任錨點(例如，根證書)。驗證過程的一個關鍵步驟在於肯定證書鏈中的一個或多個證書是否已被撤銷。如果，則驗證路徑將失效。

互聯網中實現證書撤銷的兩種方法：證書撤銷列表(CRL)和在線證書狀態協議(OCSP)[RFC2560]。

CRL：一個被簽署的列表，它指定了一套證書發佈者認爲無效的證書。除了普通CRL外，還定義了一些特殊的CRL類型用於覆蓋特殊領域的CRL。

OCSP：一個應用層的請求/應答協議，一般運行在HTTP協議之上。當用戶試圖訪問一個服務器時，在線證書狀態協議發送一個對於證書狀態信息的請求，服務器回覆一個"有效"、"過時"或"未知"的響應。

OCSP克服了CRL的缺陷：必須常常在客戶端下載以確保列表的更新。

TCP/IP安全協議與分層

存在與OSI協議棧中各層次以及一些'中間'層的安全協議，以下：

層號     層名稱       實例
7       應用層       DNSEC/DKM/EAP/Diameter/RADIUS/SSH/Kerberos/IPsec(IKE)
4       傳輸層       TLS/DTLS/PANA 
3       網絡層       IPsec(ESP)
2       鏈路層       802.1X(EAPoL)/802.1AE(MACSec)/802.11i/WPA2/EAP

網絡訪問控制

網絡訪問控制(NAC)是指對於特定系統或用戶而言用於受權或拒絕網絡通訊的方法。

由IEEE定義的802.1X基於端口的網絡訪問控制(PNAC)標準普遍用於TCP/IP網絡，爲企業局域網提供安全，其中包括有線和無線網絡。PNAC的目的在於只有當系統或用戶基於網絡接入點完成認證後，纔會爲其提供網絡訪問服務。因爲常與IETF標準的可擴展身份驗證協議(EAP)配合使用[RFC3748]，因此802.1X協議有時也稱爲局域網上的EAP協議(EAPoL)。2010年的版本[802.1X-2010]還包括了802.1AE(IEEE的局域網加密標準，稱爲MACSec)與802.1AR(面向安全設備表示的X.509證書)，還包括了一個比較複雜的MACSec密鑰協商協議MKA。

EAP可與多種鏈路層技術一同使用，並提供多種方法來實現身份驗證、受權及計費(AAA)。然而EAP自己並不執行加密，因此它必須與其餘一些加密功能矯情的協議一同才能保證安全。以下圖是EAP的一個實例設置：

上圖假設了一個包括有線和無線端點的企業網絡，這個受保護的網絡包括了AAA服務器、特殊虛擬局域網中的內網服務器以及一個不須要認證的虛擬局域網。認證者負責與未認證端點以及AAA服務器進行交互以肯定是否給予每一個端點訪問受保護網絡的權限。上圖認證者可以以'直通模式'允運行，以幫助認證者免於執行大量的認證方法。

EAP數據包的格式很是簡單，如圖所示：

代碼字段包含了6中EAP數據包類型之一：請求(1)、響應(2)、成功(3)、失敗(4)、初始化(5)、結束(6)。

標識符字段包含了一個由發送者選擇的序號，用於匹配請求與響應。

長度字段給出了EAP消息的字節數(含代碼、標識符、長度)。

典型的EAP交互過程：

　　1. 從認證者發送一個請求消息給端點；

　　2. 端點以一條響應消息做爲迴應，兩條消息使用的格式相同。

請求與響應消息的主要目的在於交換實現成功認證所須要的信息，以下圖：

EAP消息承載着端點與認證者之間的認證材料。

EAP是一個支持自身的多路複用與多路分解的分層體系結構，從概念上講，它包括四個層次：底層、EAP層、EAP端點/認證者層、EAP方法層。底層負責有序的傳輸EAP幀；EAP層實現可靠性和消除重複；EAP端點/認證者層負責實現端點與認證者協議的消息，基於對代碼字段的多路分解實現；EAP方法層包含了全部用於認證的特殊方法，包含任何用於處理大消息的協議操做。

網絡接入認證信息承載協議(PANA)做爲EAP的下次，扮演着EAP信息承載者的角色，它使用UDP/IP協議(端口號716)，所以可以用於多種類型的鏈路，而且不限於點對點的網絡模型。

PANA的框架包含了三個主要的功能性實體，PANA客戶端(PaC)、PANA認證代理(PAA)、PANA中繼原件(PRE)：

　　PANA的用途一般包含認證服務器(AS)和執行點(EP)，AS是一個經過訪問協議訪問的常規AAA服務器。

　　PAA負責將認證材料從PaC傳輸至AS，而且在網絡訪問被批准或撤銷時對EP進行配置。

　　PaC與PAA之間的直接通訊不能實現時，PRE可用於二者之間的中繼通訊。

PANA協議由一組請求/響應消息構成，包括一個有"屬性-值"對組成的擴展集合。PANA會話包含4個節點：認證/受權、訪問、從新認證、終止。從新認證明際上是訪問階段的一部分，因此從新認證後會話的生存期也獲得相應的擴展。終止節點通常會以明確的方式進入，也會由於會話超時而進入。

PANA是一個弱傳輸協議，它按照"stop-and-wait"模式工做，沒有使用自適應的重傳計時器，不可以對數據包進行從新分組。當出現多個數據包丟失的狀況時，它的重傳計時器會以指數的方式進行回退。

IP安全(IPsec)

IPsec的操做可分爲創建階段和數據交換階段。創建階段負載交換密鑰材料並創建安全管理(SA)；數據交換階段會使用不一樣類型的封裝架構，稱爲認證頭部(AH)與封裝安全負載(ESP)。

一個完整的IPsec包含了SA創建協議、AH(可選)、ESP以及一些合適的加密套件、配置信息與設置工具。[RFC6071]總結了全部IPsec組件的發展過程與當前規範。

IPsec會有選擇地針對某些數據包進行操做，這些操做基於管理員所設定的策略。全部的策略都包含在一個安全策略數據庫(SPD)中，邏輯上與每個IPsec的實現相伴。IPsec還須要兩個額外的數據庫，稱爲安全關聯數據庫(SAD)和端點認證數據包(PAD)。下圖簡單的描述了須要如何使用這些數據庫及如何處理數據包：

SA

IPsec的第一步就是創建SA，SA是在兩個通訊方之間創建的單工(單向)認證關聯。常見的狀況是雙方之間的雙向通訊，所以須要一對SA纔能有效地使用IPsec，特殊協議Internet密鑰交換(IKE)自動完成這項工做。IKE開始於一個簡單的請求/響應消息對，該消息對包括一個創建如下參數的請求：加密請求、完整性保護算法、Diffie-Hellman組，以及根據任何輸入的比特串隨機生成輸出的PRF(PRF用於生成會話密鑰)。

IKE的前兩次交換稱爲IKE_SA_INIT和IKE_AUTH，創建一個IKE_SA和CHILD_SA。隨後出現兩個交換，其中CREATE_CHILD_SA交換用於創建其餘的CHILD_SA，INFORMATIONAL交換則用於初始化SA中的變化或收集SA的狀態信息。IKE消息封裝在UDP中經過端口500或4500發送，而IKE的接收者則應該準備接收來自任何端口的流量。

IKE消息格式以下：

SPI，安全參數索引，一個64位的號碼，用於標識一個特定的IKE_SA，發起者和響應者都會有一個屬於本身的SA，因此它們能提供正在使用的SPI，這一對SPI值可以與通訊兩端的IP地址結合起來用於造成一個有效的鏈接標識符。

下一個負載字段指出了後面負載的類型。

主要版本字和次要版本字段應分別設置爲2和0，當沒法維持版本直接的互操做性時，主要版本號就會被修改。

交換類型字段給出了消息的交換類型，包含：IKE_SA_INIT(34)，IKE_AUTH(35)，CREATE_CHILD_SA(36)，INFORMATIONAL(37)，IKE_SESSION_RESUME(38)，其餘數值被保留，240~255範圍被留做私人用途。

標誌位字段定義了一個3比特位的字段：I(發起者，第3位)，V(版本，第4位)，R(響應者，第5位)。I由原始發起者設置，接收者會在返回消息中將其清除；V指出一個版本號，高於發送者當前使用的協議的主要版本號；R指出當前消息是以前某一消息的響應，與其使用相同的消息標識符。

消息標識符字段是於TCP序列號相似的功能，標識包含該標識符的數據流的第一個字節。不一樣的是發起者消息標識符從0開始，而響應者從1開始。不管是在發送仍是接收時，消息標識符都會被記錄下，這樣作能夠幫助每個通訊端檢測重放攻擊。

長度字段統計了IKE消息頭部和全部負載的合計大小。

IKEv2負載類型表，數值0表示沒有下一個負載：

"通用"的IKEv2負載頭部以下圖所示：

通用的負載頭部固定爲32位，下一個負載與負載長度字段提供了一個大小可變的負載"鏈"(最多位65535字節，包括負載頭部的4字節)。C位指出當前負載對於一個成功的IKE交換而言被認爲是"關鍵"的。

IKE_SA_INIT與IKE_AUTH交換過程：

HDR IKE 頭部(非有效載荷)；SAi1/SAr1(SAi2/SAr2)分別表示發起者和響應者可支持的密碼算法套件，數值表示階段；KEi/KEr表示雙方的 Diffie–Hellman密鑰交換內容和一次性隨機數。

CREATE_CHILD_SA交換用於建立或更新一個CHILD_SA，或用於更新一個IKE_SA。交換過程以下：

INFORMATIONAL交換用於傳輸狀態與錯誤信息，一般使用N(通知)負載。交換過程以下：

AH

IP認證頭部(AH)[RFC4302]是IPsec協議套件的可選部分，提供了一種源認證與保護IP數據報完整性的方法。

看下IPsec AH處理後的IP頭部(IPsec頭部)：

IPsec AH處理後的隧道模式IP頭部：

AH結構：

下一個頭部字段指出下一個類型值。

負載長度字段指出AH的長度。

保留字段做爲保留。

安全參數索引字段包含一個32位的位於接收者端的SA標識符，指出AH屬於哪一個SA，隨着每個SA數據包的發送而增1。

序列號字段，若是開啓，則用於重放保護。

完整性校驗值字段是可變的，且依賴於使用的密碼套件，該字段在長度上保持爲32比特的整數倍。

ESP

IPsec的封裝安全負載(ESP)[RFC4303]，也稱做ESP(v3)(注意，其自己並不提供正式的版本號)，提供了一個可選的組合，包括機密性、完整性、原始認證以及對IP數據報的反重放保護。

看下IPsec ESP處理後的IP頭部(IPsec頭部)：

IPsec ESP處理後的隧道模式IP頭部：

ESP結構：

安全參數索引字段包含一個32位的位於接收者端的SA標識符，指出ESP屬於哪一個SA，隨着每個SA數據包的發送而增1。

序列號字段，若是開啓，則用於重放保護。

負載數據以32位(IPv6中64位)爲邊界終止，而且最後兩個8位字段可以識別填充長度與下一個頭部字段值，填充、填充長度、下一個頭部字段共同構成了ESP尾部。

完整性校驗值字段是一個長度可變的尾部，用於啓用完整性支持以及知足完整性檢驗算法的須要。它會對ESP頭部、負載以及ESP尾部進行計算。ICV的長度取決於所選擇的特定完整性檢驗方法，所以它會在相關的SA創建以後才創建起來，而且要求SA在其生存期中不發生改變。

傳輸層安全(TLS和DTLS)

傳輸層安全(TLS)用於保證Web通訊以及其餘流行協議的安全，其面向數據報的版本成爲數據報傳輸層安全(DTLS)。

TLS協議自己分爲兩層：記錄層和上層。如圖所示：

TLS是一個客戶端/服務器協議，設計用於爲兩個應用程序的鏈接提供安全。記錄協議提供分片、壓縮、完整性保護及客戶端與服務器之間所交換數據的加密服務。信息交換協議(即上層協議)負責創建身份、進行認證、提示警報、以及爲用於每一條鏈接的記錄協議提供惟一的密鑰材料，其包含4個特殊的協議：握手協議、警告協議、密碼變動協議、應用數據協議。

記錄協議

記錄協議使用一個可擴展的記錄"內容類型"值集合來識別可多路複用的消息類型。

在任何給定的時間點時，記錄協議有一個活躍的當前鏈接狀態和一組被稱爲掛起鏈接狀態的狀態參數；每個鏈接狀態又進一步被劃分爲讀狀態和寫狀態；每一個狀態又指定一個壓縮算法、加密算法和用於通訊的MAC算法，同時還包括必需的密鑰與參數。

TLS記錄過程：

壓縮算法能夠爲NULL壓縮協議，即不提供任何壓縮，且壓縮算法應該是無損的，產出的輸出結果不能大於輸入記錄的1KB。爲了防止負載被披露或修改，加密與完整性保護算法會將TLS壓縮結構轉換爲可以在底層傳輸層鏈接上發送的TLS密文結構。

消息交換協議 

TLS的三個子協議是經過數字分辨的，這些數字被記錄層用於多路複用和多路分解，好比握手協議(22)、警告協議(21)、密碼變動協議(20)。

密碼變動協議包括一個單字節的消息，該字節的數值爲1，該消息的目的在於指出通訊一方但願將當前狀態修改成掛起狀態。若是收到這條消息，就將讀掛起狀態做爲當前狀態並指示記錄層儘快轉換至掛起寫狀態。

警告協議用於從TLS臉頰的一端向另外一端傳遞狀態信息，它能夠包括一些終止條件或非致命的錯誤條件。

握手協議創建了與鏈接相關的運行參數。它容許TLS端點完成6個主要目標：協商加密算法並交換造成對稱密鑰時使用的隨機值；創建算法運行參數；交換證書並執行互相認證；生成特定的會話密鑰；爲記錄層提供安全參數；驗證全部的操做都已正確執行。

握手協議過程：

　　1. 客戶端向服務端發送第一條ClientHello消息，該消息包含：會話標識符、建議的加密套件變化(CS)、一套可接受的壓縮算法、TLS版本號、一個稱爲ClientHello.random的隨機數。

　　2. 服務端接收到ClientHello消息，檢查其中的會話標識是否存在其緩存中。若是存在，則服務端經過一個簡化的握手過程繼續以前已有的鏈接(稱爲從新開始)。服務端經過ServerHello消息將服務端的隨機數ServerHello.random傳遞至客戶端，完成了交換的第一部分。這條消息也包含一個會話標識符，若是它的數值與客戶端的數值相同，則代表服務端願意從新開始；不然其數值爲0表示須要開啓一個完整的握手過程。若是服務端須要經過身份驗證，會要求它在證書(Certificate)消息中提供本身的證書鏈。若是證書的簽名是無效的，那麼服務器可能還須要發送一個服務器密鑰交換消息，使其在沒有證書的狀況下經過一個暫時或短暫的密鑰生成會話密鑰。

　　3. 客戶端收到服務端返回信息並確認後，以一個握手協議已完成消息(Finished)結束。

以下圖：

在缺少可靠傳輸層的狀況下提供相似TLS服務的主要挑戰在於數據報可能會丟失、從新排序或重複。這些問題會影響到加密與握手協議，這二者都依賴於TLS協議。爲了處理這些問題，DTLS爲記錄層承載的每一條記錄添加了一個明確的序列號，在每一條ChangeCipherSpec消息發送以後這些序列號被重置爲0。

在DTLS中的MAC計算修改了對應的TLS版本，包含了一個由兩個新字段組成的64位塊，以容許單獨處理每一條記錄。注意：在TLS中一個錯誤的MAC會致使鏈接終止；而在DTLS中，終止一個完整的鏈接是沒有必要的，接收者會選擇簡單地丟棄包含錯誤MAC的記錄，或是發送一條警告消息。

重複的消息會被簡單地丟棄，或者被視爲一個潛在的重放攻擊。若是支持重放檢測，那麼將會在接收端設置一個當前序列號窗口。要求該窗口只是容納32條消息，建議至少64條。如下列出接收到消息後的行爲：

　　1. 若是到達記錄的序列號小於窗口左邊沿對應的數值，那麼會將它視爲舊的或重複的記錄而默默地丟棄；

　　2. 那些在窗口以內的記錄也會被檢查，看是否出現重複；

　　3. 若是一條消息在窗口以內而且擁有正確的序列號，即使出現順序錯亂的狀況也會將其保留下來；

　　4. 而那些擁有錯誤MAC的消息會被丟棄；

　　5. 有正確MAC卻超出窗口右邊沿的消息會使得右邊沿增長。

所以，右邊沿表明已驗證消息的最高序列號。

爲了處理消息丟失的問題，DTLS具備簡單的超時和重傳功能。重傳功能是以消息組的形式運行的，也被稱爲"班次"。

上圖初始的完整交換(左)包含6個班次的信息，每一個班次都可以持續傳輸。DTLS簡化交換(右上)只使用3個班次，且與TLS略不一樣。DTLS在處理協議時報錯一個擁有三個狀態的有限狀態機(右下)。

狀態機的三個狀態分別爲：準備、發送、等待。狀態機由一個重傳計時器驅動，它的默認建議值爲1秒。若是在超時期限內接收不到某一班次的響應，就會使用相同的握手協議序列號從新傳輸這一班次。然而須要注意的是，記錄層序列號仍然會向前增長。後續重傳如何沒有得到響應將會使RTX的超時值加倍，至少高達60s。在一次成功傳輸或一個長的空閒期後會重置該數值。

在DTLS中，當一臺服務器接受到一條ClientHello消息，它會生成一條心的包含32位cookie的HelloVerifyRequest消息。後續的ClientHello消息必須包含以前的cookie，不然服務器會拒絕交換。這被DTLS用於防護DoS攻擊。

DNS安全(DNSEC)

DNS的安全不只指DNS中的數據(資源記錄，RR)安全，還包含在同步或更新DNS服務器內容時的傳輸安全。針對其部署的安全機制稱爲域名系統安全擴展(DNSSEC)[RFC4033][RFC4034][RFC4035]。DNSSEC提供了DNS數據的源認證與完整性保護，以及(有限的)密鑰分發設施。DNSSEC還可以進行不存在性驗證，DNS響應可以指出某一受保護的特定域名是不存在的並對此提供保護。DNSSEC不能爲DNS信息提供保密性、DoS攻擊保護以及訪問控制。

當執行一個帶有DNSSEC的DNS查詢時，一個已知安全的解析器就會使用DNS擴展機制(EDNS0)，而且將請求中一個OPT元資源記錄的DO位置位(表示DNSSEC OK)。該位指出客戶端不只有興趣並且有能力來處理DNSSEC相關的信息並支持EDNS0。DO位在EDNS0元資源記錄的"擴展的RCODE與標誌"部分，是其中第2個16位字段的第1位。接收到那些DO位未置位(或不存在)請求時，會禁止服務器返回大多數資源記錄，除非這些記錄是在請求中明確要求的。

當服務器處理來自一個DNSSEC可用解析器的請求時，它會檢測DNS請求的CD(Checking Disabled)位，若是該位置位，那麼代表客戶端願意接收包含未驗證數據的響應。在準備一個響應時，服務器一般會利用密碼方法驗證要返回的數據，成功的驗證結果會使得響應中的AD(Authentic Data)位置位[RFC4035]。若是擁有一條到達服務器的安全路徑，那麼一個安全已知但未驗證的解析器在原則上是可以信任這條信息的。然而，最好的狀況是使用驗證存根解析器，它可以進行加密驗證，從而將查詢的CD位置位。這樣不只提供了端到端的DNS安全(即中間解析器不須要是可信的)，還減小了中間服務器的計算負擔;不然，這些中間服務器不得不進行密碼驗證。

DNSSEC 資源記錄

DNSKEY，用以維護公鑰。密鑰只能與DNSSEC一塊兒使用；其餘的資源記錄可能用於維護針對其餘用途的密鑰或證書。

DNSKEY資源記錄格式以下圖：

DNSKEY資源記錄的RDATA部分包含一個只用於DNSSEC的公鑰，標誌字段包含了一個區域密鑰指示符(第7位)，若是置位，那麼DNSKEY資源記錄擁有者的名稱必須爲區域的名稱，而且所包含的密鑰也被稱爲區域簽名密鑰(ZSK)或密鑰簽名密鑰(KSK)，若是未置位，那麼記錄將會維護另外一種不能用於驗證區域簽名的DNS密鑰；一個安全入口點指示符(第15位)做爲調試或簽名軟件時的一條提示，可以根據密鑰的用途作出明智的猜想，簽名驗證不會解釋SEP位，但該位置位的密鑰一般爲KSK，並經過驗證子區域的密鑰來確保DNS層次結構的安全；一個撤銷指示符(第8位)，若是置位，則表示密鑰不能用於驗證。算法字段指出了簽名算法，根據[RFC4034]，只有DSA與具備SHA-1的RSA(值分別爲3和5)才被定義用於DNSKEY資源記錄。公鑰字段維護了一個公鑰，它的格式依賴於算法字段。

DS，受權簽名者資源記錄用於指定一條DNSKEY資源記錄，一般從一個父區域到一個子區域。

DS資源記錄格式如圖：

密鑰標籤字段包含了對一條DNSKEY資源記錄的非惟一參考。

算法字段使用了DNSKEY資源記錄的算法字段相同的數值。

摘要類型字段指出了所用的簽名類型[RFC4034]中只定義了數值1(SHA-1)，SHA-256是經過[RFC4509]指定的。

摘要字段包含了將要引用的DNSKEY資源記錄的摘要，該摘要計算方法以下：

    摘要 = 摘要算法(DNSKEY全部者名|DNSKEY RDATA)

此處的"|"是鏈接運算符，而DNSKEY RDATA的數值是根據引用的DNSKEY資源記錄來計算的，計算方法以下：

    DNSKEY RDATA = 標誌 | 協議 | 算法 | 公鑰

在SHA-1狀況下，摘要長度爲20字節；在SHA-256狀況下，長度爲32字節。

NSEC/NSEC3，NextSECure，下一個安全資源記錄用於規範有序的名稱或一個NS類型的RRset(資源記錄集)受權點中維護"下一個"RRset全部者的域名，它還維護位於NSEC資源記錄的全部者名稱中的RR類型列表，這樣可以爲區域結構提供認證與完整性驗證。

NSEC資源記錄格式如圖：

下一個域名字段維護一個區域的規範有序的域名鏈中的下一個條目。

類型位圖字段維護了一張關於RR類型的位圖，這些RR類型記錄在NSEC資源記錄全部者的域名中。

NSEC3是對NSEC結構作的優化，旨在消除"任何人可以經過遍歷NSEC鏈而列舉出一個區域中的權威記錄"這個問題(也被稱爲區域列舉)。

NSEC3資源記錄格式如圖：

散列算法字段標識了應用於下一個全部者名稱的散列函數，以產生下一個散列的全部者字段。

標誌字段的低比特位包含了一個opt-out標誌，若是置位，它將指出NSEC3記錄可能包含未簽名的受權。

迭代次數字段指出散列函數使用了多少次，較大的迭代次數有助於防止找到與NSEC3記錄中的散列數值相關的全部者名稱(字典攻擊)。

混淆值長度字段給出了混淆值字段的字節長度，包含了一個在計算散列函數以前附加於原全部者名稱的數值，目的在於幫助抵禦字典攻擊。

爲了得到下一個散列全部者字段的散列值，須要進行如下計算：

    IH(0) = H(全部者名稱 | 混淆值)
    IH(k) = H(IH(k - 1) | 混淆值)， 若 k > 0
    下一個散列全部者 = H(IH(迭代次數) | 混淆值)

其中H是散列算法字段指定的散列函數，全部者名稱必須按照標準的格式。迭代次數與混淆值取自NSEC3資源記錄的相關字段。

爲了不混淆NSEC與NSEC3資源記錄類型，[RFC5155]在NSEC3資源記錄的區域中分配並要求使用特殊的安全算法編號6和7，做爲標識符3(DSA)和5(SHA-1)的別名。

RRSIG，資源記錄簽名的資源記錄用於簽署並驗證RRset中的簽名。區域中每一條受權的資源記錄都必須簽名，一條RRSIG資源記錄包含了某一特定RRset的數字簽名以及使用哪個公鑰來驗證簽名的信息。

RRSIG資源記錄格式如圖：

覆蓋類型字段指出了簽名適用的RRset類型，它的數值來自標準的RR類型集合。

算法字段指出了簽名算法。

標籤字段給出了在RRSIG資源記錄的原全部者名稱中的標籤數目。

源TTL字段維護了一份TTL副本，這份副本是當RRset出現於受權區域時保留下來的。

簽名到期與簽名成立字段指出了一個簽名有效期的開始和結束時間。

密鑰標籤字段標識那些用於得到某種特殊公鑰的DNSKEY資源記錄。

DNSSEC運行 

對於一個特殊的資源記錄而言，須要有一個定義良好的規範形式：

　　1. 每個域名都是一個徹底限定域名並被徹底展開(無壓縮標籤)。

　　2. 在全部者名稱中的全部大寫的US-ASCII碼字符都須要被它們的小寫版本代替。

　　3. 對於任何類型號爲2~九、十二、1四、1五、1七、1八、2一、2四、2六、3三、3五、3六、39以及38的記錄，在它們的RDATA部分出現的域名中，全部大寫的US-ASCII碼字符都須要被它們的小寫版本代替。

　　4. 任何通配符都不會被取代。

　　5. 當出如今源權威區域或覆蓋RRSIG資源記錄的源TTL字段，TTL將會設置爲原始值。

DNSSEC依賴於簽名區域。這樣的區域包括RRSIG、DNSKEY以及NSEC(或NSEC3)資源記錄，並且若是有一個簽名受權點，它還可能包含DS資源記錄。簽名使用公鑰加密，公鑰的存儲於分發經過DNS來完成。

以下圖展現了位於父子區域之間的抽象受權點：

父區域包含了本身的DNSKEY資源記錄，它可以提供與使用RRSIG資源記錄來簽名一個區域中的全部受權RRset的私鑰相關的公鑰。父區域中的一條DS資源記錄提供子頂點的一條DNSKEY資源記錄的散列值，這樣就能見了起一條從父區域到子區域的信任鏈。一個信任父區域的DS資源記錄的驗證解析器也能驗證子區域的DNSKEY資源記錄，以及最終的RRSIG和子區域中籤名的RRset(該狀況只有在驗證者擁有一個與父區域DSNKEY資源記錄相連的信任根節點時纔會發生)。

事務認證(TSIG,TKEY,SIG(0))

DNSSEC提供了數據的源認證與區域數據的完整性保護，而事務認證爲客戶端與服務器之間不檢查交換內容正確性的特殊事務提供了完整性保護與認證。DNS中的事務(如區域傳輸、動態更新)安全並不直接保護DNS的內容，因此它和DNSSEC是互補的，須要可以被一同部署。

主要有兩種方法來認證DNS的事務：TSIG和SIG(0)。SIG使用共享密鑰而SIG(0)使用公鑰/私鑰對，爲了緩解部署的負擔，可使用TKEY資源記錄類型來幫助造成TSIG或SIG(0)的密鑰。

針對DNS或事務簽名的密鑰事務認證(TSIG)[RFC2845]5]使用基於共享密鑰的簽名爲DNS交換添加事務認證，TSIG使用一個按需計算而且只用於保障一次事務的TSIG僞資源記錄。

TSIG僞資源記錄格式如圖：

上面的資源記錄是包含在DNS請求與響應的附加數據部分發送的。

算法名稱字段指出使用什麼算法。

簽名時間字段是按照UNIX系統的時間格式組織的，而且給出了消息內容被簽署的時間，此字段隱藏在數字簽名中，被設計用於檢測並抵禦重放攻擊，此處使用一個絕對時間的結果是，使用TSIG的端點必須在更新字段指定秒數內對時間達成一致。

MAC大小字段給出了MAC字段中包含的MAC與其依賴的特殊MAC算法所需的字節數。

源ID字段是該消息的一個標識，與DNS的事務ID匹配。

錯誤字段用以承載錯誤信息。

其餘長度字段給出了其餘數據字段的字節數，通常用來運送錯誤的消息。

SIG(0)[RFC2931]沒有覆蓋DNS中靜態的記錄，而是爲交換動態地生成，SIG(0)的0部分指一條被簽署資源記錄中數據的長度。SIG(0)記錄原則上可以替代TSIG資源記錄，並達到相同的結果，但他們是以不一樣的方法實現的。更重要的是，SIG(0)將信任基礎放置於公鑰中來代替共享密鑰。

TKEY元資源記錄類型旨在簡化DNS交換安全的部署，爲了完成這項工做，它會動態建立TKEY資源記錄並添加到DNS請求與響應的附加信息部分發送出去，它們可以包含密鑰或者用於造成密鑰的資料，好比DH公共數值。

域名密鑰識別郵件 

域名密鑰識別郵件(DKIM)[RFC5585]提供了一個實體與一個域名之間的關聯，從而決定哪一方發送初始消息，特別是以電子郵件形式。域名密鑰識別郵件的工做是經過在基本的Internet消息格式中添加一個DKIM簽名實現的[RFC5322]，該字段包含了對消息頭部和消息體的數字簽名。DKIM取代了早期稱爲域名密鑰的標準，該標準使用域名密鑰簽名字段。

爲生成一條消息的數字簽名，簽名域表示符(SDID)會使用RSA/SHA-1或者RSA/SHA-256算法及相關的私鑰。SDID來自DNS的域名，並用於檢索以TXT資源記錄存儲的公鑰。一個DKIM簽名會經過Base64被編碼爲一個消息頭部字段，該簽名可以簽署一個明確列出的消息字段與消息體集合。

當接收到一封電子郵件時，郵件傳輸代理會使用SDID來實現一個DNS查詢，從而找出相關的公鑰。該公鑰會在以後用於驗證簽名，這樣就避免了請求一個PKI的工做。所擁有的域名是由域自己和選擇器(公鑰選擇器)一塊兒構成的。例如，在域example.com中的選擇器key35的公鑰是一條由key35._domainkey.example.com擁有的TXT資源記錄。

 參考：

《TCP IP 詳解卷1：協議》

RFC官方文檔