1 / 46

Guide to Information Security

Guide to Information Security. Computer Science&Technology School of Shan d ong University. Chapter 14 – Authentication Applications. Instructor: Hou Mengbo Email: houmb AT sdu.edu.cn Office: Information Security Research Group. Authentication Applications.

herman
Télécharger la présentation

Guide to Information Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Guide to Information Security Computer Science&Technology School of Shandong University Chapter 14 – Authentication Applications Instructor: Hou Mengbo Email: houmb AT sdu.edu.cn Office: Information Security Research Group

  2. Authentication Applications • will consider authentication functions • developed to support application-level authentication & digital signatures • will consider Kerberos – a private-key authentication service • then X.509 directory authentication service

  3. KerberosAuthentication Protocol

  4. Kerberos Authentication Protocol • Kerberos Overview • Kerberos Protocol Description • KerberosAnalysis and related Resources

  5. What’s Kerberos ？ • 1988由MIT开发，在一个分布式环境中，用于服务器与用户之间的相互认证的协议。 • 名称来源于希腊神话，Kerberos是地狱入口的守护者，通常有三个头。 • 设计者的设计初衷是要用Kerberos的三个头来守卫网络之门。三个头包括：认证、帐目清算以及审计。 • 到目前共有5个版本。1、2、3版为实验室版。第4、5版得到广泛应用。第5版和第4版基本原理一致，只对第4版做了部分改进。

  6. Kerberos 要解决的问题 • 在一个开放的分布式网络环境中，用户通过工作站访问服务器提供的服务。存在很多问题： • 工作站上的用户可以冒充另一用户操作。 • 用户可以改变工作站地址冒充另一台工作站。 • 用户可以窃听并回放他人的信息交换，获得对于某种服务的访问权或中断服务的运行。 • 使用假冒服务器从而骗得用户的机密信息。

  7. Kerberos 的解决方案 • 在一个分布式的Client/Server体系机构中，引入一个可信任的第三方（Kerberos服务器），让其提供认证服务。 • 采用共享密钥加密技术。

  8. Kerberos 基本性质 • 安全：使网络窃听者不能获得必要的信息来伪装成另一客户。 • 可靠：对所有以Kerberos进行访问控制的服务来说，客户无法通过Kerberos服务器的认证就意味着无法获得所需要的服务。 • 透明：用户除了需要输入一个口令外，不必知道认证过程的存在以及细节。 • 可伸缩：可支持大量用户和服务器。（采用模块化、C/S结构）

  9. Kerberos 应用 • Kerberos 第5版 是Windows 2000 中最基本的安全协议，是默认的用户和服务器验证提供者。 • Linux 、Unix 类系统也都支持Kerberos协议。 • 作为网络环境的双向认证协议。

  10. 三个概念 在一个开放的网络环境中，所有用户都可以向任一服务器请求服务。每个服务器为了认证用户的合法性就必须知道每一个用户口令。显然网络规模越大维护越复杂，所以引入： 认证服务器（AS）：它将所有用户的口令集中存放在本地数据库中；而且它与每一个应用服务器共享一个唯一的密钥。（密钥通过物理的或其他安全的方式分发） 客户端（C）：代替用户与服务器进行信息交换。 票据（Ticket） ：身份或权利的证明。 Ticket由 AS以数据报形式发放给C。

  11. 对话过程 (1) C  AS : IDc || Pc || IDv (2) AS  C : Ticket (3) C  V : IDc || Ticket Ticket = EKv [ IDc || ADc || IDv ] 字符说明 C ＝客户端 AS ＝认证服务器 V ＝服务（服务器） IDc ＝在C上的用户标识 IDv ＝V的标识符 Pc ＝在C上的用户口令 ADc ＝C的网络地址 Kv ＝AS与V共享加密密钥 || ＝级联 一个简单的认证对话

  12. 两个最突出问题： • 用户每次访问一种新服务就需要一个新的票据，导致用户多次输入口令。 • 用明文传递的用户口令会被窃听。

  13. 解决方案 • 票据许可服务器 （TGS）向已经通过TGS认证的用户发放服务Ticket。用户首先向AS请求一张票据许可票 Tickettgs，并将它保存在 C 中。每当用户要求一种新的服务时，客户便用这张能认证自己的 Tickettgs向TGS发出申请。TGS给用户发回一张针对某种特定服务的服务许可票据 TicketV，客户将保留每一个TicketV，在每次请求相同服务时提供给服务器 V 来认证。 • Ticket 重用，设置生命期。

  14. Once per user logon session: (1) C  AS : IDc || IDtgs (2) AS  C : EKc [ Tickettgs ] Once per type of service: (3) C  TGS: IDc||IDv||Tickettgs (4) TGSC: TicketV Once per service session: (5) CV: IDc || TicketV Tickettgs = EKtgs [ IDc || ADc || IDtgs|| TS1 || Lifetime1] TicketV = EKV[ IDc || ADc || IDV|| TS2 || Lifetime2] 符号说明 IDtgs＝TGS的标识符 Kc＝由用户口令导出的密钥 TS1＝时间戳 TimeStamp Lifetime1＝ 生存期 改进的认证对话

  15. 改进版过程说明 (1) 客户通过向AS发送用户ID、TGS ID来请求一张代表该用户的票据许可票据。 (2) As发回一张加密过的票据作为响应，加密密钥是由用户口令导出的散列码。响应到达客户端后，客户端提示用户输入口令，产生密钥，解密报文。口令正确，票据正确恢复。 (3)客户端代表用户请求一张服务许可票据。 (4)TGS 对收到的 Tickettgs 进行解密，通过检查TGS ID来验证解密是否成功。并检查票据的生存期，确保没有过期。比较用户ID和网络地址与通过 AS 认证用户的信息是否一致。若允许用户访问V，TGS 发回一张该TicketV。两种票据的结构完全相同。 (5)客户端 C 代表用户请求某项服务。向 V 发送用户ID和 TicketV 服务许可票据的报文。应用服务器解密票据。通过检查 IDV来验证解密是否成功。并检查票据的生存期，确保没有过期。比较用户ID和网络地址与通过 TGS 认证用户的信息是否一致。一致则向用户提供服务。

  16. 仍然存在的两个问题 • 很难选择Ticket的生存期长短。短：用户多次重复输入口令；长：对手窃听网络得到Ticket后，可在生存期结束前获得合法用户的资源。 （一般为8小时） • 服务器不能向用户认证自己。

  17. 解决方案 • 会话密钥（Session Key）让 AS以安全的方式向 C 和 TGS提供同一个会话密钥，然后 C 向TGS出示用 Session Key 加密个人信息（认证符）|| Ticket 来证明身份。同样，TGS 向 C 和 V 作同样的事情。 • 认证符：使用Session Key 加密（用户ID、地址、时间戳）的报文。 Session Key 是安全的，V 在对 Ticket 认证之后，将认证符的时间戳+1，并用 Session Key 加密发还给 C ； C使用 Session Key解密，得到时间戳+1，和前次发送的认证符中的时间戳比较，来认证服务器。

  18. Kerberos 第4版

  19. 第4版 报文交换总结（一） • 认证服务交换：获得票据许可票据 (1) CAS : IDC || IDtgs || TS1 IDC： 客户端将用户的身份标识告诉给AS IDtgs ：告诉AS用户想要请求的TGS TS1：允许AS验证客户端的时钟是否与AS同步 (2) ASC : EKc[Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs] Tickettgs = EKtgs[Kc,tgs|| IDC || ADC || IDtgs || TS2 || Lifetime2 ] Ekc：用基于用户口令的散列码来加密，使AS和C能够验证口令，并保护报文(2) Kc,tgs ：由AS生成允许客户端与TGS间安全交换报文 TS2 ：通知客户端票据发出的时间 Lifetime2：通知客户端票据的有效期 Tickettgs：客户用来访问TGS的票据

  20. 第4版 报文交换总结（二） • 票据许可服务交换：获得服务许可票据 (3) CTGS : IDV || Tickettgs || AuthenticatorC (4) TGSC : Kc,tgs [KC,V|| IDV || TS4 || TicketV ] TicketV = EKv [KC,V|| IDC || ADC || IDV || TS4 || Lifetime4 ] AuthenticatorC = E Kc,tgs [ IDC || ADC || TS3 ] IDV ：告诉TGS用户访问的应用服务器V Tickettgs ：使TGS确信该用户以通过AS的认证 TicketV ：客户用来访问服务器V的票据 AuthenticatorC：由客户端产生认证符，证明票据的有效性 ADC ：防止非法用户在另一台工作站上使用该票据 TS3 ：通知TGS此认证符产生时间。

  21. 第4版 报文交换总结（三） • 客户/服务器认证交换：获得服务 (5) CV : TicketV || AuthenticatorC (6) VC : EKc,v [TS5 +1 ] AuthenticatorC = E Kc, v [ IDC || ADC || TS5 ] TicketV ＝EKv[K C,V || IDC || ADC || IDV || TS4 || Lifetime4 ] EKc,v ：使客户端确信该报文来自V,仅有客户和服务器知道的密钥加密以防篡改。 TicketV ：使服务器V确信该用户已经通过AS的验证 K C,V ：客户端获得会话密钥的副本；用来解密认证符，以认证票据 AuthenticatorC：由客户端产生认证符，证明票据的有效性 TS4：由通知服务器该票据发出的时间 TS5 +1 ：使C确信这不是就回答的重放

  22. 完整的Kerberos环境包含一个kerberos服务器、许多客户和许多应用服务器，同时必须满足以下两个条件：完整的Kerberos环境包含一个kerberos服务器、许多客户和许多应用服务器，同时必须满足以下两个条件： (1) Kerberos 服务器数据库必须包含所有的参与用户的ID和用户口令的散列码。所有用户都想Kerberos服务器注册。 (2) Kerberos 服务器必须与每一个服务器共享唯一的密钥。 这样的一种环境叫做 Kerberos Realm。 当用户需要访问其他Realm的服务器时，Kerberos 提供了多个Realm 间的认证机制。为了支持这种机制互操作的两个Realm之间必须满足一个条件： (3) 每个互操作Realm中Kerberos服务器要与另一Realm中Kerberos服务器共享唯一的密钥。它们必须相互注册。 Kerberos Realm 和多个Kerberos

  23. 请求另一Realm中的服务 (1) CAS : IDC || IDtgs || TS1 (2) ASC : EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs] (3) CTGS : IDrem || Tickettgs || AuthenticatorC (4) TGSC : Kc,tgs [KC,tgsrem || IDtgsrem || TS4 || Tickettgsrem ] (5) CTGSrem : IDVrem || Tickettgsrem || AuthenticatorC (6) TGSrem C : Kc,tgsrem [KC,Vrem || IDVrem || TSb || TicketVrem ] (7) C  Vrem : TicketVrem || AuthenticatorC

  24. 第5版做的主要改进 • 对加密算法的依赖性 • 对TCP/IP 协议的依赖性 • 报文字节序 （big endian-> little endian） • 票据有效期：8 bit表示（5~1280分钟） (双字节表示)有任意长度有效期。 • 认证的转发：4版不允许将发给一个用户的认证证书转发给其他主机或服务器。5版允许。例如，某客户向打印服务器请求（打印其在文件服务器上的文件），打印服务器使用客户访问认证证书从文件服务器中取该客户的文件。此时，TGS代表客户充当代理，客户向AS申请设置了PROXIABLE标志位的票据许可票据，TGS收到后，向有不同的网络地址并且设置PROXY标志的服务许可票据，应用服务器代替客户做出相应的请求。 • 领域间的认证：4版中，若有N个领域，需要有 N(N-1)/2 个Kerberos之间的安全密钥交换。第5版引用DNS解析的原理，领域组织为树状的层次结构，客户可以沿着树向上走到一个公共节点，然后在向下走到目的域。移动的每一步，域中的TGS都要将票据许可票据转发到路径中的下一个TGS。 • 取消重复加密：4版中，报文2、4，提供给客户的票据被加密两次，一次采用目标服务器的密钥，一次采用客户知道的密钥。5版去掉了不必要的第二次加密。 EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs] EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 ] || Tickettgs

  25. 功能特性分析 • 可信的第三方Kerberos服务器 • 所需的密钥分配和管理变简单 • AS负担认证工作，减轻应用服务器负担 • 安全相关数据集中管理和保护，使攻击者入侵难以成功 • Ticket • 使AS（TGS）的认证结果和会话密钥安全传给C和TGS（应用服务器） • 生存期内可重用，减少认证开销，提高方便性 • 共享密钥 • 为认证提供安全依据

  26. 功能特性分析 • TGS • 降低用户口令的使用频度，提供更好的口令保护 • 减轻AS负担，提高系统效率 • Session Key • 防止非法用户窃得Ticket进行重放攻击 • 提供了对服务器得认证 • 时间戳 • 防止对Ticket和认证符的重放攻击

  27. 局限性分析 • Kerberos服务器易受攻击 • 它的安全性决定了整个系统得安全性，若此关键环节发生问题，危害是灾难性的。 • 口令攻击 • 对手截获基于口令的密钥加密的内容，采用暴力破解成功后，得到口令也就到该用户的全部资源 • 域间认证复杂

  28. 资源 • 掌握Kerberos概念的简单方法请参考： http://web.mit.edu/kerberos/www/dialogue.html • MIT Kerberos 站点 http://web.mit.edu/kerberos/ • USC/ISI Kerberos 站点 http://www.isi.edu/gost/info/kerberos/

  29. X.509 Authentication Service • part of CCITT X.500 directory service standards • distributed servers maintaining some info database • defines framework for authentication services • directory may store public-key certificates • with public key of user • signed by certification authority • also defines authentication protocols • uses public-key crypto & digital signatures • algorithms not standardised, but RSA recommended • X.509 certificates are widely used

  30. X.509 Certificates • issued by a Certification Authority (CA), containing: • version (1, 2, or 3) • serial number (unique within CA) identifying certificate • signature algorithm identifier • issuer X.500 name (CA) • period of validity (from - to dates) • subject X.500 name (name of owner) • subject public-key info (algorithm, parameters, key) • issuer unique identifier (v2+) • subject unique identifier (v2+) • extension fields (v3) • signature (of hash of all fields in certificate) • notation CA<<A>> denotes certificate for A signed by CA

  31. X.509 Certificates

  32. Obtaining a Certificate • any user with access to CA can get any certificate from it • only the CA can modify a certificate • because cannot be forged, certificates can be placed in a public directory

  33. CA Hierarchy • if both users share a common CA then they are assumed to know its public key • otherwise CA's must form a hierarchy • use certificates linking members of hierarchy to validate other CA's • each CA has certificates for clients (forward) and parent (backward) • each client trusts parents certificates • enable verification of any certificate from one CA by users of all other CAs in hierarchy

  34. CA Hierarchy Use

  35. Certificate Revocation • certificates have a period of validity • may need to revoke before expiry, eg: • user's private key is compromised • user is no longer certified by this CA • CA's certificate is compromised • CA’s maintain list of revoked certificates • the Certificate Revocation List (CRL) • users should check certs with CA’s CRL

  36. Authentication Procedures • X.509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures

  37. One-Way Authentication • 1 message ( A->B) used to establish • the identity of A and that message is from A • message was intended for B • integrity & originality of message • message must include timestamp, nonce, B's identity and is signed by A

  38. One-Way Authentication

  39. Two-Way Authentication • 2 messages (A->B, B->A) which also establishes in addition: • the identity of B and that reply is from B • that reply is intended for A • integrity & originality of reply • reply includes original nonce from A, also timestamp and nonce from B

  40. Two-Way Authentication

  41. Three-Way Authentication • 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks • has reply from A back to B containing signed copy of nonce from B • means that timestamps need not be checked or relied upon

  42. Three-Way Authentication

  43. X.509 Version 3 • has been recognised that additional information is needed in a certificate • email/URL, policy details, usage constraints • rather than explicitly naming new fields defined a general extension method • extensions consist of: • extension identifier • criticality indicator • extension value

  44. Certificate Extensions • key and policy information • convey info about subject & issuer keys, plus indicators of certificate policy • certificate subject and issuer attributes • support alternative names, in alternative formats for certificate subject and/or issuer • certificate path constraints • allow constraints on use of certificates by other CA’s

  45. Public Key Infrastructure

  46. Summary • have considered: • Kerberos trusted key server system • X.509 authentication and certificates

More Related