IT Security 1 (Ch7~Ch10)

# IT Security 1 (Ch7~Ch10) ## Chapter 7: Kerberos - **什麼是Kerberos** - 在網路中提供authentication及key agreement的協定們 - 使網路應用程式可以授權他們的peers - 基於shared secret key - 基於Needham and Schroeder protocol (in Ch6.) - 流程： 1. $A$ 用帳號密碼登入工作站 2. $A$ 向 Key Distribution Center (KDC) 請求 Ticket 3. $A$ 用 Ticket 向 File system 取得授權 - **Key Distribution Center (KDC)** - 包含： - Kerberos Authentication Server (AS) - Kerberos Ticket Granting Server (TGS) - KDC提供ticket和session key - Principle Identifiers - form: $\{\text{name}\}:\text{instance@realm}$ - $\text{realm}$ 說明domain - $\text{instance}$ 說明裝置種類(ex. printer) - $\text{name}$ 是在特殊 $\text{realm}$ 中特殊 $\text{instance}$ 的實際名稱 - **protocol** - **Long-term keys:** - $KDC$ 有一把自己的密鑰 $k_{KDC}$ - $KDC$ 跟 user $A$ 有一把 secret master key $k_A$ (從 $A$ 的密碼而來) - $KDC$ 跟 resource $R$ 有一把 secret master key $k_R$ - $KDC$ 用 $k_{KDC}$ 加密這些key，並從在database - **Ticket Granting Tickets:** - $A$ 登入後，工作站向 $KDC$ 請求session key - $KDC:$ - 產生session key $S_A$ - 產生 ticket granting ticket (TGT) $\text{TGT}$$=k_{KDC}\{\text{"Alice"},$$S_A$$\text{,timestamp, lifetime}\}$ > $\text{TGT}$ 用來給 $S_A$，且 $KDC$ 不儲存任何狀態資訊 - 傳送 $k_A\{\text{"KDC"},$ $S_A$ $,$ $TGT$$\}$ 給工作站 - 工作站用 $A$ 的密碼解密，得到session key $S_A$ > 用session key而不是master key減少對password的使用 > password的攻擊更困難 - **Tickets :** - Ticket request: $A$ 向 $KDC$ 要求對 $R$ 的權限 - 工作站傳送 $\text{TGT, "R", }S_A(\text{timestamp})$ - $KDC$ 解開 $\text{TGT}$，得到 $S_A$ - $KDC$ 產生 - session key $k_{AR}$ - $\text{ticket}_R$$=k_{R}\{\text{"Alice"},$$k_{AR}$$\text{,timestamp, lifetime}\}$ - $KDC$ 回傳 $S_A\{\text{"R"},$ $k_{AR}$ $,$ $\text{ticket}_R$$\}$ - **Login into the Resource R:** - $A$ 對 $R$ 傳送 $(\text{ticket}_R$$,k_{AR}(\text{timestamp}))$ - $R$ 回傳$k_{AR}(\text{timestamp+1})$ - **Multiple KDC** - 因為一個主要的KDC會有failure或流量過大的問題 - Kerberos支援realm 1的使用者請求realm 2的資源 - Realm 2的KDC像Realm 1的resource - **Key Version Numbers** - 若 $A$ 有了ticket但 $R$ 更改了master key則會有問題 - 因此需要定義key version - $R$ 需要有前一個key，並在pre-defined的時間刪除 - **保障Encryption及Integrity:** - 用DES in PCBC (Plaintext-Cipher-Block-Chaining) mode - **PCBC:** - encryption: - $c_0:=IV$ $m_0:=0$ - $c_{n+1}:=E_k(m_{n+1}\oplus c_n\oplus m_{n})$ - decryption: - $m_{n+1}=D_k(c_{n+1})\oplus c_n\oplus$$m_n$ $m_{n+1}=D_k(c_{n+1})\oplus c_n\oplus$$D_k(c_{n+n})\oplus c_{n-1}\oplus m_{n-1}$ $m_{n+1}=D_k(c_{n+1})\oplus c_n\oplus D_k(c_{n+n})\oplus c_{n-1\oplus ... \oplus D_k(c_1)\oplus c_0}$ - 跟CBC不同的是：CBC的$c_i$經過竄改後只會影響$m_i$和$m_{i+1}$，PCBC會影響$m_i,...,m_n$ - **Problem:** - 攻擊者仍可對調 $c_i,c_j$ 使解密還是正確 - 不提供 integrity - **Network Layer Addresses in the Tickets** - $KDC$ 應檢查 $\text{TGT}$ 中的 IP address是否跟request時的IP address一樣 - 使攻擊更難因為需偽造IP address - **Kerberos v4的限制:** - 觀念上： - 只能用DES in PCBC mode保障encryption和integrity - usable only on top of IP(!?) - Message byte傳送的順序是sender決定的 - ticket lifetime太短 - 不支援委託(ticket無法轉移) - principle naming的問題：無法在 $\text{name}$ 加入 "." - Ticket's Double encryption - 技術上： - PCBC mode: non-standard DES mode，沒有integrity保障 - replay - Password attacks：因為密文包含 $\text{"KDC"}$，所以會被猜測密碼 ### Kerberos 5 - 支援不同的加密演算法 - private-message type: - DES-CBC-Hash - Hash: CRC, MD4, MD5 - safe-message type: - RSA-MD5-DES - DES-MAC - DES-MAC-k (not recommanded) - RSA-MD4-DES - RSA-MD4-DES-k (not recommanded) - 還有Specification 2 - 不只用IP，還有支援其他address type - Principal naming限制更少 - Encoding problems (byte ordering) solved by the use of standard encodings (ANS.1 syntax with the Basic Encoding Rules) - TGT跟ticket的改變 - 不再加密"KDC"到TGT中 - | | Kerberos 4 | Kerberos 5 | | -------- | -------- | -------- | | TGT-Reply| $k_A\{\text{"KDC"},$ $S_A$ $,$ $\text{TGT}$$\}$ | $k_A\{S_A\},$ $\text{TGT}$ | | Ticket-Reply | $S_A\{\text{"R"},k_{AR},\text{ticket}_R\}$ | $S_A\{\text{"R"},k_{AR}\},$ $\text{ticket}_R$ | > 不會雙重加密 $\text{TGT},\text{ticket}_R$ - **New features:** - 另外的授權機制，在TGT-request中的pre-authenticated data - 用sequence number取代timestamp - 支援代理機制 - $A$ 向 $ADC$ 請求 $P$ 的 ticket(有 $P$ 的address) - $P$ 的行為代表 $A$ - $A$ 可以控制 $P$ 的權限 - 可以有Flag標註是 $P$ 還是 $A$ - 有Proxiable Ticket Flag和Forwardable Ticket Flag - 供應用程式決定要不要接受此ticket - ticket lifetime - 時間更彈性 - 可以renew - 可以要求之後的ticket - 階層性的realm - 可以有short-cut，減少request次數 - Pre-authentication - 送出 $\text{TGT-request}$ 時加上 pre-authentication data - 避免字典攻擊、denial of service攻擊(過量的request) - 可以用public key crytographic - KDC儲存certificate而不是password ## Ch8. IPsec - IPsec: IP security - - 網路架構 - Application (e.g. SNMP, HTTP, FTP) - Presentation (e.g. encryption, ASCII, PNG, MIDI) - Session (e.g. Syn/Ack) - Transport (e.g. TCP, UDP, port numbers) - **Network (e.g. IP, routers)** - Data Link (e.g. MAC, switches) - Physical (e.g. cable, RJ45) - 可以用additional headers的方式被加到IPv4, IPv6的能力 - 包含authentication, confidentiality(保密) 和 key management - IPsec在transport layer以上是對應用程式透明 - 應用： - 公司內部LANs的連線 over 公開的WAN - 各host - 各router - | IP Header | Payload | | IP Header | IPsec Header | Protected Payload | - IPsec支援兩種mode - transport mode | | | | | - tunnel mode $|\ \ \ \ |$ - security protocols AH and ESP 兩者mode皆可用 - **transport mode:** - 一個新header或一個header+trailer會加在IP header跟payload中間 - Protected IP Packet包含original IP header - **Tunnel Mode:** - 在Original IP packet前(後)加header(trailer) - 新的outer IP header在Protected IP packet前 - **AH(Authentication Header protocol)** - 用來授權從source host到destination host的封包 - 用IP header保障integrity - 防止replay - 用MAC - 加在transport mode/ tunnel mode的新header - **AH 的位置** - | IP Header | AH | TCP/UDP header | Payload | - | Outer IP Header | AH | Inner IP Header | TCP/UDP header | Payload | - **ESP Protocol(Encapsulated Security Payload)** - 提供 packet-level source 授權、integrity、replay保護、保密 - 加上header, trailer, MAC - 加密payload - **NULL Encryption** - do nothing - test_case = 1 data = 0x123456789abcdef data_len = 8 NULL_data = 0x123456789abcdef - **ESP in two modes** - **Tranport mode** - | IP Header | ESP header | TCP/UDP header | Payload | ESP trailer | MAC | - **Tunnel mode** - | Outer IP Header | ESP header | Inner IP Header | TCP/UDP header | Payload | ESP trailer | MAC | - **ESP v.s. AH** <table> <tr> <td>AH</td> <td>ESP</td> </tr> <tr> <td></td> <td>payload confidentiality</td> </tr> <tr> <td>outer IP header 的integrity </td> <td></td> </tr> <tr> <td></td> <td>Inner IP header 的integrity</td> </tr> <tr> <td colspan="2">Payload integrity</td> </tr> <tr> <td colspan="2">Replay protection (用sequence number)</td> </tr> <tr> <td colspan="2">Data source authentication</td> </tr> </table> - **Security Associations (SAs)** - IPsec保障的單方面通訊 - 每個SA都有 - Security Parameter Index (SPI) 在AH or ESP header中，用來保護package - Security Protocol Identifier 說明是AH或 ESP protocol - 參數： - Sequence Number Counter - Sequence Counter Overflow - Anti-Replay Window - AH Information - ESP Information - Lifetime of this SA - IPsec Protocol Mode - Path MTU(maximum transmission unit) - **SA selectors** - 在SAD(SA-database)中定義各selector - 包含 - 來源IP - 目的IP - 來源目的port - 通訊協定 - 一個Data來 - 若在SAD中找不到selector，則跳過IPsec的步驟 - 若有selector則找對應的SA，選擇對應的AH/ESP - 若沒有對應的SA，則用 Internet Key Exchange Protocol(IKE) 跟某個SA協調 - **ISAKMP (Internet Security Association and Key Management Protocol)** - 定義 key exchange 授權的 message format - 支援peers之間的SA協調 - 兩個phase: - Phase 1 協調一對SA以保護phase 2的ISAKMP - Phase 2 保護協調SA以用在其他協定(AH/ESP) - **為何兩個phase** - 相同的phase 1可以用在不同的phase 2 - 相同的安全通道可以有不同的SA - Key refreshment可以只在phase 2執行 - **Phase 1** <table> <tr> <td>Aggressive mode</td> <td>Main mode</td> </tr> <tr> <td colspan="2">支援 authentication 和 session key establishment</td> </tr> <tr> <td>3 messages</td> <td>6 messages</td> </tr> <tr> <td></td> <td>額外保護endpoint identifiers</td> </tr> <tr> <td></td> <td>強制執行</td> </tr> <tr> <td>跟DoS protection有問題</td> <td></td> </tr> </table> - **Dos (Denial of Service) protection with cookies** - header有cookies用來提供Dos protection - Dos(Denial of Service)是因為資源耗盡 - header中的cookie確保responder是無狀態的，直到initiator傳送兩個訊息 - responder的狀態會被存在無法忘記的cookie中，並傳給initiator - initiator回答後，cookie會被再次生成，跟上個initiator回傳的cookie做比較 - 成本是兩個增加的messages - **Typical Anti-DoS Cookie** - Typical protocol: 1. Client 送 request Message #1 2. Server建立連線，回傳 Message #2 3. Client 結束或建立DoS攻擊 - Cookie version: 1. Client 送 request 2. Server 送 Hash 後的 connection data ，只有server有 key 3. Client 確認後回傳 Hash 資料 4. 傳送延後的 Message #2 - **Signatures, Aggressive Mode** - Main mode都是先用key exchange的方式建立公鑰私鑰，再傳遞加密後的ID,signature等 - Signatures, Aggressive Mode是把key exchange所需的資料與ID一起傳遞，再生成公鑰私鑰，傳遞signature - Signature必須在responder’s cookie前生成，可能有**DoS攻擊** - **IKEv2和IKEv1比較** | IKEv1 | IKEv2 | | -------- | -------- | | | 較少RFCs | | | 較少phase 1 exchanges的選擇 | | | 在IKE exchange (phase1)時IPsec的一對SA已建立 | ||chile SA建立| ||不強制用cookies| ## Ch9. SSL/TLS - 協定適用： - Server授權 / Server和Client授權 - transport layer的Integrity和(optional)機密性 - applications可呼叫的session-based保護(eg. http) - **S**ecure **S**ocket **L**ayer (SSL) - **T**ransport **L**ayer **S**ecurity (TLS) ### TLS - **TLS session** - 是server和client之間的association - 由handshake protocol生成 - 可以被shared - 演算法、加密方法相關 - **TLS connection** - transport layer connection提供一連串服務 - 點對點關係 - 短暫的 - 跟session有關 - key、參數相關 - **Handshake protocol** 1. 建立cipher suite 2. server 證明和key交換 3. (client 證明和)key交換 4. 結束handshake - 結束handshake之後會得到一master secret - 從此master secret可得其他sessions key用來加密或integrity保障 - 四種key exchange方法 - RSA - Anonymous DH - Ephemeral DH - Fixed DH - 不同方法步驟2和3會不同 - **RSA** 1. Client得到 $\text{RSA(certificate)}$ 2. Client產生一隨機key叫 pre-master secret 3. Client用server的公鑰加密pre-master secret 4. Server用自己的私鑰解密 - **DH-Anonymous** 1. Client和Server交換未簽章的public DH values 2. 雙方計算pre-master secret - 易受Man-in-the-Middle attacks但是是匿名的 - **Ephemeral(短暫的) DH (DHE)** 1. Client和Server計算Ephemeral private DH values 2. 傳送 public DH values 用RSA或DSS簽章 3. 用 public DH values 和 private DH values 計算pre-master secret - **Fixed DH** 1. Client和Server用certification authority簽章的fixed public DH values 2. 用 public DH values 和 private DH values 計算pre-master secret - **Server-side-only authentication** - 用RSA - server端DHE，client端DH-anonym - server端Fixed DH，client端DH-anonym - **雙方 authentication** - Client和Server用DHE - Client和Server用Fixed-DH - Client和Server混用DHE和Fixed-DH - Client和Server用RSA，Client簽章certificate > 是由Server決定要哪種方法 - **Phase: Finish** - $\text{PRF(x)}$$\text{=PRF(master secret, "Finish" || hash(handshake_messages))}$ - $\text{master secret}$$\text{=PRF (}$$\text{pre-master secret}$$\text{,"master secret"|| ClientHello.random || ServerHello.random)}$ > $\text{PRF}$ 是一個 pseudo random function - **ChangeCipherSpec Protocol** - 定義ChangeCipherSpec message，用來作handshake protocol的一部分 - **Session Resumption(恢復)** - 因為session setup是overhead - **Problems:** - server的performance限制 - DoS攻擊 - Session resumption： - 可以重複使用Pre-Master-secret - 但生成新random number以生成新的master secret - **Record Protocol** - pending state的參數 - handshake protocol的參數 - 用法： - 對 upper layer 的 payload 操作 - Output 的 TLS payload 包含 壓縮、integrity保護、加密 - 另 output 一個 record protocol header 說明 protocol 內容 - Validation (Certificate) 是由 application 所做，而非TLS/SSL

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.