Kerberos

  • Initially developed at MIT
    • 作為 remote authentication 的標準
  • 一個受信任的第三方驗證服務
    • 用戶端與伺服器都信任 Kerberos 來協調彼此的身分驗證
    • 要求:
      • 使用者在每次使用服務時，都必須證明其身分
      • (可選) 伺服器也需要向用戶端證明其身分

Security Issues between Clients and Servers

  • 在未受保護的網路環境中，任何客戶端都可以向任何伺服器申請服務
  • Impersonation (冒充): 假裝成其他客戶端，從而在伺服器上取得未授權的權限
  • 使用 Authentication Server (AS): AS 驗證了使用者身分，就可以將該資訊傳遞給應用伺服器
    • 如果客戶端透過網路將密碼傳送給 AS，攻擊者可能會攔截並取得該密碼

Kerberos Overview

  • AS 會與每一台伺服器共享一個唯一的 secret key
  • Session key: 一次性使用的加密金鑰
    • 保護下一次通訊
  • Ticket 與 Session key 都會使用使用者的密碼作為加密金鑰進行加密
  • 密碼本身不會在網路上傳輸
  • Ticket: 一組憑證，包含:
    • User’s ID, server’s ID, a timestamp, a lifetime
  • 整個 Ticket 會使用 AS 與伺服器之間共享的秘密 DES 金鑰進行加密
  • 為什麼需要 TGS:
    • 若每次存取服務都要重新向使用者詢問密碼: 不方便
    • 若將密碼儲存在記憶體中 (登入期間): 有安全風險
  • TGS 的作用: 用 Ticket 來取得更多 Ticket
    • 只需登入一次，之後透過 TGS 就可以取得各個服務的 Ticket

如何防範 Ticket-Granting Ticket 的威脅

  • Ticket 可能被竊取並 reused
    • Timestamp
  • Ticket 被竄改 (alteration)
    • 使用只有 AS 與 TGS 知道的 secret key 加密
  • User spoofing (偽裝)
    • 基於使用者密碼進行加密驗證
  • Replay attack
    • 使用不可重複使用的 Authenticator
    • Timestamp

Kerberos Realms

  • Kerberos realm: 一個完整的 Kerberos 環境，包含:
    • A Kerberos server
    • A number of clients
      • 每個客戶端都需向 Kerberos 伺服器註冊，伺服器會維護使用者 ID / 密碼的資料庫
    • A number of app servers
      • 每個應用伺服器也需向 Kerberos 伺服器註冊，並與其共享 secret key
  • 不同的 realms: 由不同管理組織所控制的客戶端與伺服器網路

Interrealm Authentication

  • 每個 realm 的 Kerberos server 之間會共享 secret key
    • server 之間彼此註冊: 信任對方

Kerberos Versions 4 and 5

  • Most widely used: Version 4 in late 1980s
  • Version 5
    • Now widely implemented
    • AES is the default choice (DES in v4)
    • Authentication forwarding
      • 允許客戶端存取某個伺服器，並由該伺服器代表客戶端去存取另一個伺服器

Performance Issues

  • 在大型環境中，對效能的影響非常小
    • 前提是系統有正確配置
    • 用於取得 ticket 的網路流量需求不高
  • 是否需要專用平台?
    • 不建議與高資源消耗的應用程式運行在同一台機器上
    • 為了安全性，最好將其部署在獨立、隔離的機器上
  • 使用多個 realms 來提升效能是否可行?
    • 通常不建議
    • 設立多個 realms 的主要動機是管理需求

X.509: Public-key Certificate

  • A certificate
    • 將 public key 與其擁有者的身分綁定
    • 由受信任的第三方進行數位簽章
  • Third party: certificate authority (CA)
    • 被使用者社群所信任
    • ex: 政府機構、金融機構
  • 使用者以安全方式將自己的 public key 提交給 CA 後取得 certificate
  • X.509: Specified in RFC 5280
    • 最廣泛被接受的公開金鑰憑證格式
  • Usage restriction (使用限制)
    • Key Usage and Extended Key Usage 用來指定該金鑰被允許的用途
  • 如果憑證被破解或遭到入侵怎麼辦? 如何撤銷 (revoke)
  • A certificate revocation list (CRL)
    • 由簽發憑證的機構（issuer / CA）簽署
    • 包含被撤銷憑證的序號 (serial number) 以及撤銷日期
    • 在收到憑證時，應查詢該 CA 的最新 CRL: high overheads
  • A lightweight protocol for the revocation in RFC 6960
    • 已被多數現代網頁瀏覽器支援
    • Authority Information Access 擴充欄位: 提供伺服器位址
    • 直接向該伺服器查詢憑證狀態
  • Hash signature
    • MD5 collisions are found in 2012
    • SHA-1 collisions are discovered in 2017
    • Using SHA-2 and SHA-3 now

Public-Key Infrastructure (PKI)

  • RFC 4949
    • PKI 是一組完整系統，包含硬體、軟體、人員、政策與流程
    • 用於建立、管理、儲存、分發與撤銷基於非對稱加密的數位憑證
  • 讓使用者能安全、方便且有效率地取得他人的公開金鑰
  • Current X.509 PKI implementations: trust store
    • 系統內建一組受信任的 CA 清單及其 public keys

CAs in Trust Store

  • 可以直接簽署 end-user certificate
  • 或先簽署少數 Intermediate CAs
    • They in turn sign end-user certificates
  • All the hierarchies are very small, and all are equally trusted
    • 作用: 降低 Root CA 暴露風險，提升安全性
  • 可被自動驗證的憑證: 從 trust store 中的 CA 所取得的憑證

紅字整理

P6: Kerberos Overview

  • AS verifies user’s access right in database, creates ticket-granting ticket and session key. Results are encrypted using key derived from user’s password.