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 所取得的憑證

Issues with the PKI Model

  1. 當憑證驗證出現問題時，系統會要求使用者自行決定是否接受
    • 一般使用者通常缺乏足夠的安全知識，容易做出錯誤選擇
  2. 假設 trust store 中所有 CA 都同樣可信
    • 不同 CA 管理品質與安全性差異很大
  3. 不同瀏覽器與 OS 有各自的 trust stores
    • 同一個網站在不同環境下可能顯示不同的安全狀態

Improve the X.509 Certificates

  • 在許多 Web 應用中，使用者真正需要的是確認自己每次造訪的是同一個安全網站
    • 網站與其金鑰與之前造訪時相同
  • Improvement 1: 時間上的連續性 (continuity in time)
    • 應用程式會記錄過去曾造訪網站的憑證資訊
    • Google Chrome
  • Improvement 2: 空間上的連續性 (continuity in space)
    • 使用網路公證伺服器 (network notary servers) 記錄各個網站的憑證
    • Firefox “Perspectives” plugin
    • notary servers: Google Certificate Catalog

OAuth and OpenID

OAuth (Open Authorization) 2.0

  • 一種 授權委派 (access delegation) 的開放標準

  • 授權網站或應用程式在不需要密碼的情況下，存取他在其他網站上的資料

  • 已被許多知名公司採用

  • 讓 client 能代表 resource owner 安全地存取 server 上的資料

  • 流程:

    • resource owner 授權第三方應用，不需要提供帳號密碼
    • authorization server 發放 access token
    • client 使用 access token 存取 resource server 中的受保護資源

OAuth 2.0 for Authentication

OpenID

紅字整理

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.