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

AH	ESP
	payload confidentiality
outer IP header 的integrity
	Inner IP header 的integrity
Payload integrity
Replay protection (用sequence number)
Data source authentication

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

Aggressive mode	Main mode
支援 authentication 和 session key establishment
3 messages	6 messages
	額外保護endpoint identifiers
	強制執行
跟DoS protection有問題

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)
Secure Socket Layer (SSL)
Transport Layer Security (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.

IT Security 1 (Ch7~Ch10)

Chapter 7: Kerberos

Kerberos 5

Ch8. IPsec

IPsec: IP security

Ch9. SSL/TLS

TLS