460 likes | 637 Views
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.
E N D
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
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
Kerberos Authentication Protocol • Kerberos Overview • Kerberos Protocol Description • KerberosAnalysis and related Resources
What’s Kerberos ? • 1988由MIT开发,在一个分布式环境中,用于服务器与用户之间的相互认证的协议。 • 名称来源于希腊神话,Kerberos是地狱入口的守护者,通常有三个头。 • 设计者的设计初衷是要用Kerberos的三个头来守卫网络之门。三个头包括:认证、帐目清算以及审计。 • 到目前共有5个版本。1、2、3版为实验室版。第4、5版得到广泛应用。第5版和第4版基本原理一致,只对第4版做了部分改进。
Kerberos 要解决的问题 • 在一个开放的分布式网络环境中,用户通过工作站访问服务器提供的服务。存在很多问题: • 工作站上的用户可以冒充另一用户操作。 • 用户可以改变工作站地址冒充另一台工作站。 • 用户可以窃听并回放他人的信息交换,获得对于某种服务的访问权或中断服务的运行。 • 使用假冒服务器从而骗得用户的机密信息。
Kerberos 的解决方案 • 在一个分布式的Client/Server体系机构中,引入一个可信任的第三方(Kerberos服务器),让其提供认证服务。 • 采用共享密钥加密技术。
Kerberos 基本性质 • 安全:使网络窃听者不能获得必要的信息来伪装成另一客户。 • 可靠:对所有以Kerberos进行访问控制的服务来说,客户无法通过Kerberos服务器的认证就意味着无法获得所需要的服务。 • 透明:用户除了需要输入一个口令外,不必知道认证过程的存在以及细节。 • 可伸缩:可支持大量用户和服务器。(采用模块化、C/S结构)
Kerberos 应用 • Kerberos 第5版 是Windows 2000 中最基本的安全协议,是默认的用户和服务器验证提供者。 • Linux 、Unix 类系统也都支持Kerberos协议。 • 作为网络环境的双向认证协议。
三个概念 在一个开放的网络环境中,所有用户都可以向任一服务器请求服务。每个服务器为了认证用户的合法性就必须知道每一个用户口令。显然网络规模越大维护越复杂,所以引入: 认证服务器(AS):它将所有用户的口令集中存放在本地数据库中;而且它与每一个应用服务器共享一个唯一的密钥。(密钥通过物理的或其他安全的方式分发) 客户端(C):代替用户与服务器进行信息交换。 票据(Ticket) :身份或权利的证明。 Ticket由 AS以数据报形式发放给C。
对话过程 (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共享加密密钥 || =级联 一个简单的认证对话
两个最突出问题: • 用户每次访问一种新服务就需要一个新的票据,导致用户多次输入口令。 • 用明文传递的用户口令会被窃听。
解决方案 • 票据许可服务器 (TGS)向已经通过TGS认证的用户发放服务Ticket。用户首先向AS请求一张票据许可票 Tickettgs,并将它保存在 C 中。每当用户要求一种新的服务时,客户便用这张能认证自己的 Tickettgs向TGS发出申请。TGS给用户发回一张针对某种特定服务的服务许可票据 TicketV,客户将保留每一个TicketV,在每次请求相同服务时提供给服务器 V 来认证。 • Ticket 重用,设置生命期。
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) TGSC: TicketV Once per service session: (5) CV: IDc || TicketV Tickettgs = EKtgs [ IDc || ADc || IDtgs|| TS1 || Lifetime1] TicketV = EKV[ IDc || ADc || IDV|| TS2 || Lifetime2] 符号说明 IDtgs=TGS的标识符 Kc=由用户口令导出的密钥 TS1=时间戳 TimeStamp Lifetime1= 生存期 改进的认证对话
改进版过程说明 (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 认证用户的信息是否一致。一致则向用户提供服务。
仍然存在的两个问题 • 很难选择Ticket的生存期长短。短:用户多次重复输入口令;长:对手窃听网络得到Ticket后,可在生存期结束前获得合法用户的资源。 (一般为8小时) • 服务器不能向用户认证自己。
解决方案 • 会话密钥(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,和前次发送的认证符中的时间戳比较,来认证服务器。
第4版 报文交换总结(一) • 认证服务交换:获得票据许可票据 (1) CAS : IDC || IDtgs || TS1 IDC: 客户端将用户的身份标识告诉给AS IDtgs :告诉AS用户想要请求的TGS TS1:允许AS验证客户端的时钟是否与AS同步 (2) ASC : 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的票据
第4版 报文交换总结(二) • 票据许可服务交换:获得服务许可票据 (3) CTGS : IDV || Tickettgs || AuthenticatorC (4) TGSC : 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此认证符产生时间。
第4版 报文交换总结(三) • 客户/服务器认证交换:获得服务 (5) CV : TicketV || AuthenticatorC (6) VC : 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确信这不是就回答的重放
完整的Kerberos环境包含一个kerberos服务器、许多客户和许多应用服务器,同时必须满足以下两个条件:完整的Kerberos环境包含一个kerberos服务器、许多客户和许多应用服务器,同时必须满足以下两个条件: (1) Kerberos 服务器数据库必须包含所有的参与用户的ID和用户口令的散列码。所有用户都想Kerberos服务器注册。 (2) Kerberos 服务器必须与每一个服务器共享唯一的密钥。 这样的一种环境叫做 Kerberos Realm。 当用户需要访问其他Realm的服务器时,Kerberos 提供了多个Realm 间的认证机制。为了支持这种机制互操作的两个Realm之间必须满足一个条件: (3) 每个互操作Realm中Kerberos服务器要与另一Realm中Kerberos服务器共享唯一的密钥。它们必须相互注册。 Kerberos Realm 和多个Kerberos
请求另一Realm中的服务 (1) CAS : IDC || IDtgs || TS1 (2) ASC : EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs] (3) CTGS : IDrem || Tickettgs || AuthenticatorC (4) TGSC : Kc,tgs [KC,tgsrem || IDtgsrem || TS4 || Tickettgsrem ] (5) CTGSrem : IDVrem || Tickettgsrem || AuthenticatorC (6) TGSrem C : Kc,tgsrem [KC,Vrem || IDVrem || TSb || TicketVrem ] (7) C Vrem : TicketVrem || AuthenticatorC
第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
功能特性分析 • 可信的第三方Kerberos服务器 • 所需的密钥分配和管理变简单 • AS负担认证工作,减轻应用服务器负担 • 安全相关数据集中管理和保护,使攻击者入侵难以成功 • Ticket • 使AS(TGS)的认证结果和会话密钥安全传给C和TGS(应用服务器) • 生存期内可重用,减少认证开销,提高方便性 • 共享密钥 • 为认证提供安全依据
功能特性分析 • TGS • 降低用户口令的使用频度,提供更好的口令保护 • 减轻AS负担,提高系统效率 • Session Key • 防止非法用户窃得Ticket进行重放攻击 • 提供了对服务器得认证 • 时间戳 • 防止对Ticket和认证符的重放攻击
局限性分析 • Kerberos服务器易受攻击 • 它的安全性决定了整个系统得安全性,若此关键环节发生问题,危害是灾难性的。 • 口令攻击 • 对手截获基于口令的密钥加密的内容,采用暴力破解成功后,得到口令也就到该用户的全部资源 • 域间认证复杂
资源 • 掌握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/
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
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
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
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
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
Authentication Procedures • X.509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures
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
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
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
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
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
Summary • have considered: • Kerberos trusted key server system • X.509 authentication and certificates