信息系统安全 第四章 身份认证

信息系统安全 第四章 身份认证

概述

身份认证是验证主体的真实身份与其所声称的身份是否相符的过程,也是信息系统的第一道安全防线。

身份认证包括标识和鉴别两个过程。

  • 标识(Identification):是系统为区分用户身份而建立的用户标识符,一般是在用户注册到系统时建立,用户标识符必须是唯一的且不能伪造
  • 鉴别(Authentication):将用户标识符与用户物理身份联系的过程,鉴别要求用户出示能够证明其身份的特殊信息,并且这个信息是秘密的或独一无二的,任何其他用户都不能拥有它

常见的身份认证:

  • 利用用户所知道的东西:口令、密码等
  • 利用用户所拥有的东西:智能卡、密钥盘等
  • 利用用户所具有的生物特征:指纹、声音等
  • 利用用户的行为特征:签名、击键等

一般情况下,可以通过多个因素共同鉴别用户的身份。

基于口令的认证

口令认证过程

最常用的一种身份认证技术。用户事先在服务器上进行注册,尽力自己的用户账号,包括用户标识符和口令。这些信息存储在服务器口令表中,只有用户自己和服务器知道。

口令机制存在的安全问题:

  • 口令指令不高
    • 仅有数字字母组成的口令,弱口令
    • 字典攻击:收集用户可能的口令构成字典,逐一尝试
    • 穷举攻击:尝试所有可能的口令
  • 口令明文存储
    • 数据库中存放用户的明文口令
  • 口令嗅探和重放攻击
    • 截获传输的口令,进行重放攻击
  • 攻击者利用社会工程学、键盘记录器等获取口令

口令认证安全增强机制

  • 提高口令质量
    • 增加口令的复杂度和长度
    • 用户使用口令登录,采取更严格的控制措施
      • 登陆时间限制
      • 限制登录次数
      • 尽量减少会话透露的信息
  • 口令加密存储
    • 服务器口令文件存储用户名和口令的散列值
  • 口令加密传输

一次性口令的认证

静态口令:在一定时间内是不变的,可重复使用的口令,极易被嗅探劫持和重放攻击。

针对静态口令的缺陷,提出利用散列函数产生一次性口令(One Time Password, OPT)的思想。即用户每次登录过程,加入不确定因素以声称动态变化的示证信息。如:短信密码、验证码、口令卡等。

上述一次性口令机制比较简单,在传输中没有进行加密。更为安全的一次性口令是以密码学为基础的。根据动态因素不同,主要分为两种实现技术;同步认证技术和异步认证技术。其中同步认证技术又分为基于时间同步认证技术(Time Synchronous)和基于事件同步认证技术(Event Synchronous);异步认证技术即为挑战/应答技术(Challenge/Response)。

基于时间同步的认证技术

动态因素是登录时间。为了使服务端能产生和用户相同的口令以验证用户的身份,该方案要求用户和认证服务器的时钟必须严格一致。

例如手机令牌。基于时间同步的方式,每隔 30s 产生一个随机 6 位动态密码。

有点事操作简单、携带方便。难点在于需要解决好网络延迟等不确定因素带来的干扰。

挑战/应答方式

基本原理:每次认证,服务器产生一个随机数(挑战)发送给客户端,客户端以该随机数作为不确定因素,用某种单项算法计算出结果作为应答,服务器通过验证应答的有效性来判断客户端身份的合法性。

最为经典的挑战/应答方案是 S/Key 方案,分为注册和认证两个过程。注册只执行一次,认证在每次登录时都要执行。

  1. S/Key 注册过程

    1. 新用户选择将在服务器上注册的用户名 ID、口令 PW,并提交给服务器,服务器为该 IP 选择随机种子 Seed 和最大迭代数 Seq,并将 Seed 和 Seq 发送给用户
    2. 用户收到 Seed 和 Seq 后,对 Seed || PW 进行 Seq 次 Hash 运算,将计算结果 \(H_{seq}(Seed||PW)\) 通过安全信道发送给认证服务器
    3. 服务器收到 \(H_{seq}(Seed||PW)\) 后,将其与对应的用户 ID 保存在认证数据库,同时将 Seq-1 保存
  2. S/Key 认证过程

    当用户第 i 次登陆时,在用户登录的服务器上当前保存的认证数据有用户 ID、\(H_{seq-i+1}(Seed||PW)\) 和迭代次数 (Seq-i),第 i 次登录认证过程如下:

    1. 用户发送登录请求,并将 ID 发送给给服务器,服务器从数据库中取出对应的种子 Seed 和迭代次数 (Seq-i),并发送给用户
    2. 用户收到 Seed 和(Seq-i)后,计算 \(H_{seq-i}(Seed||PW)\),将其发送给认证服务器
    3. 服务器收到后,计算 \(H(H_{seq-i}(Seed||PW))\),与数据库中 \(H_{seq-i+1}(Seed||PW)\) 相比较,若相同,认证通过,登陆成功,并用 \(H_{seq-i}(Seed||PW)\) 替换原来的 \(H_{seq-i+1}(Seed||PW)\),否则认证失败,拒绝登录请求

S/Key 口令序列存在的攻击方式:

  • 小数攻击:黑客截取 Seed 和 Seq,并将 Seq 改为较小值,发给用户,后获的用户后续的一系列口令
  • 协议破坏攻击
  • 内部人员攻击

基于智能卡的认证方式

磁卡曾经广泛使用,但仅有数据存储能力,而无数据处理能,容易伪造和复制。

智能卡(CPU 卡),是一种嵌有单片机芯片的 IC 卡(Integrated Circuit card),不仅可以读写和存储数据,还可以对数据进行处理。

个人识别号(PIN,Personal Identification Number),验证持卡人是否是本人的号码。

USB Key,外型和 U 盘类似,其特点:

  • 双因素认证
    • 每个 USB Key 都有硬件 PIN 码,用户只有同时取得 USB Key 和用户 PIN 码才能登陆
  • 带有安全存储空间
    • 具有 8-128KB 的安全数据存储空间,存储数字证书、用户密钥等秘密数据,且读写操作都需程序实现,无法直接读取
  • 硬件实现加密算法
    • 内置 CPU 或智能卡芯片,可实现 PKI 体系的各种算法,运算只在 USB key 内运行,不出现在计算机内存中

USB Key 身份认证系统的模式:

  • 基于挑战-应答的双因素认证方式
    • 客户端向服务器发送验证请求
    • 服务器生成随机数并发送给客户端
    • 客户端将收到的随机数通过 USB 接口提供给智能卡计算,运算出结果作为认证证据发送给服务器
    • 服务器也用该随机数与存储在服务器数据库中的该客户密钥进行相同运算
    • 若结果相同,则认为客户端合法
  • 基于数字证书的认证方式
    • 智能卡中产生公私密钥对的程序烧制在芯片的 ROM 中,密码算法程序也是烧制在 ROM 中,公私秘钥在智能卡中产生后,公钥可以导出至卡外生成数字证书后存储在 USB Key 中,而私钥不允许外部访问

基于生物特征的认证方式

基于生物特征的身份认证方式是利用人体固有的生理特征或行为特征来进行身份识别或验证。如指纹、眼睛虹膜、声音、人脸、笔迹、步态等。

一般过程:

  1. 对用户的生物特征进行多次采样,特征提取后存储在数据库中
  2. 鉴别时,对用户的生物特征进行采样,特征提取发送给认证系统
  3. 认证系统比较 1 和 2 的特征,返回结果

特点:随身性、安全性、唯一性、稳定性、广泛性、方便性、可采集性。

身份认证协议

服务器验证用户身份,称为单向认证(One-Way Authentication),若还要鉴别服务器身份,则为双向认证(Two-Way Authentication)。

单向认证

采用对称密码体制实现单向认证

  • Alice 向 Bob 提出认证请求
  • Bob 产生一个随机数 \(R_B\) 发送给 Alice
  • Alice 用双方共享的密钥 \(K_{A-B}\) 加密该随机数后发送给 Bob
  • Bob 如果用相同的密钥解密得到 \(R_B\),则 Alice 身份验证通过

采用非对称密码体制实现单向认证

  • Alice 向 Bob 提出认证请求
  • Bob 产生一个随机数 \(R_B\),并用 Alice 的公钥加密后发送给 Alice
  • Alice 用私钥解密得到随机数后发送给 Bob
  • Bob 验证随机数,若与 \(R_B\) 相同,则 Alice 身份通过认证

双向认证

用对称密码体制实现双向认证

  • Alice 向 Bob 提出认证请求
  • Bob 产生一个随机数 \(R_B\) 发送给 Alice
  • Alice 产生一个随机数 \(R_A\),串接在 \(R_B\) 后,用双方共享的密钥 \(K_{A-B}\) 加密后发送给 Bob
  • Bob 如果用相同的密钥解密后,分解能得到 \(R_B\),则 Alice 身份验证通过;同时将 \(R_A\)\(R_B\) 调换顺序串接后发用共享密钥加密后发送给 Alice
  • Alice 如果用相同的密钥解密后,分解能得到 \(R_A\),则 Bob 身份验证通过

用公钥密钥体制实现双向认证

  • Alice 产生一个随机数 \(R_A\),并用 Bob 的公钥加密后发送给 Bob
  • Bob 用私钥解密得到 \(R_A\),产生一个随机数 \(R_B\) 串接在 \(R_A\) 后用 Alice 的公钥加密后发送给 Alice
  • Alice 用自己的私钥解密,如果能分理出 \(R_A\),则验证通过 Bob 的身份;同时将解密分离出来的 \(R_B\) 发送给 Bob
  • Bob 接收到之后可以验证 Alice 的身份

可信的第三方认证

借助双方给都能信任的第三方认证。如 Kerberos 协议中的 KDC(Key Distribution Center)。

Kerberos 协议中,主要参与方为 Client、Server、KDC。Client 和 Sever 之中通过 KDC 进行通信。

整个 Kerberos 认证过程大体分为 3 个子过程:

  1. Client 向 KDC 申请 TGT(Ticket Granting Ticket)
  2. Client 通过 TGT 向 KDC 申请用于访问 Server 的 Ticket
  3. Client 最终为了 Server 对自己的认证提交 Ticket

严格意义上讲,这个个子过程对应 3 个 sub-protocol:

  • Authentication Service Exchange
  • Ticket Granting Service Exchange
  • Client/Server Exchange

Authentication Service Exchange

Client 向 KDC 的 AS(Authentication Service)发送 Authentication Service Request(KRB_AS_REQ), 为了确保 KRB_AS_REQ 仅限于自己和 KDC 知道,Client 使用自己的 Master Key 对 KRB_AS_REQ 的主体部分进行加密(KDC 可以通过 Domain 的 Account Database 获得该 Client 的 Master Key )KRB_AS_REQ 的大体包含以下的内容:

  • Pre-authentication data:包含用以证明自己身份的信息。一般地,它的内容是一个被 Client 的 Master key 加密过的 Timestamp
  • Client name & realm:Domain name
  • Server Name:注意这里的 Server Name 并不是 Client 真正要访问的Server 的名称,实际上是 KDC 的 TGS(Ticket Granting Service)的 Server Name

AS 通过它接收到的 KRB_AS_REQ 验证发送方的是否是在 Client name & realm中声称的那个人,也就是说要验证发送放是否知道 Client 的 Password。所以AS 只需从 Account Database 中提取 Client 对应的 Master Key 对 Pre-authentication data 进行解密,如果是一个合法的 Timestamp,则可以证明发送放提供的是正确无误的密码。验证通过之后,AS 将一份 Authentication Service Response(KRB_AS_REP)发送给 Client。KRB_AS_REQ 主要包含两个部分:本 Client 的 Master Key 加密过的 Session Key(SKDC-Client:Logon Session Key)和被自己(KDC)加密的 TGT。而TGT大体又包含以下的内容:

  • Session Key:SKDC-Client:Logon Session Key
  • Client name & realm:Domain name
  • End time:TGT到期的时间。

Client 通过自己的 Master Key 对第一部分解密获得 Session Key(SKDC-Client:Logon Session Key)之后,携带着 TGT 便可以进入下一步:TGS(Ticket Granting Service)Exchange。

TGS(Ticket Granting Service)Exchange

Client 向 KDC 中的 TGS 发送 Ticket Granting Service Request(KRB_TGS_REQ)。KRB_TGS_REQ 大体包含以下的内容:

  • TGT:Client 通过 AS Exchange 获得的Ticket Granting Ticket,TGT 被KDC 的 Master Key 进行加密
  • Authenticator:用以证明当初 TGT 的拥有者是否就是自己,所以它必须以 TGT 的办法和自己的 Session Key(SKDC-Client:Logon Session Key)来进行加密
  • Client name & realm:Domain name。
  • Server name & realm:Domain name,Server 是 Client 试图访问的那个 Server

TGS 收到 KRB_TGS_REQ 在发给 Client 真正的 Ticket 之前,先得证明 Client 提供的那个 TGT 是否是 AS 颁发给它的。于是它不得不通过 Client 提供的Authenticator 来证明。但是 Authentication 是通过 Logon Session Key(SKDC-Client)进行加密的,而自己并没有保存这个 Session Key。所以TGS 先得通过自己的 Master Key 对 Client 提供的 TGT 进行解密,从而获得 Logon Session Key(SKDC-Client),再通过这个 Logon Session Key(SKDC-Client)解密 Authenticator 进行验证。验证通过向对方发送 Ticket Granting Service Response(KRB_TGS_REP)。这个 KRB_TGS_REP 有两部分组成:使用 Logon Session Key(SKDC-Client)加密过用于 Client 和 Server 的 Session Key(SServer-Client)和使用 Server 的 Master Key 进行加密的 Ticket。该Ticket 大体包含以下一些内容:

  • Session Key:SServer-Client。
  • Client name & realm:Domain name。
  • End time::Ticket 的到期时间。

Client 收到 KRB_TGS_REP,使用 Logon Session Key(SKDC-Client)解密第一部分后获得 Session Key(SServer-Client)。有了 Session Key 和 Ticket,Client 就可以之间和 Server 进行交互,而无须在通过 KDC 作中间人了。

#### CS(Client/Server )Exchange

Client 通过TGS Exchange 获得 Client 和 Server 的 Session Key(SServer-Client),随后创建用于证明自己就是 Ticket 的真正所有者的 Authenticator,并使用 Session Key(SServer-Client)进行加密。最后将这个被加密过的Authenticator 和 Ticket 作为 Application Service Request(KRB_AP_REQ)发送给 Server。除了上述两项内容之外,KRB_AP_REQ 还包含一个 Flag 用于表示 Client 是否需要进行双向验证(Mutual Authentication)。

Server 接收到 KRB_AP_REQ 之后,通过自己的 Master Key 解密 Ticket,从而获得 Session Key(SServer-Client)。通过 Session Key(SServer-Client)解密 Authenticator,进而验证对方的身份。验证成功,让 Client 访问需要访问的资源,否则直接拒绝对方的请求。

对于需要进行双向验证,Server 从Authenticator 提取 Timestamp,使用 Session Key(SServer-Client)进行加密,并将其发送给 Client 用于 Client 验证 Server 的身份。

kerberos 内容来自 https://blog.csdn.net/wulantian/article/details/42418231

零知识证明

零知识证明:证明者能够在不向验证者提供任何有用的信息的情况下,通过验证。

洞穴问题:

C、D 之间有一道门,P 知道打开的方法。P 要向 Q 证明 P 知道开门的方法,却不能告诉 Q 开门的方法。方法如下:

  1. C 站在 A 点,让 P 进入洞内,这样 V 不知道 P 从哪边进入洞内(左边进到达 C,右边进到达 D)
  2. 当 P 到达 C 或 D 时,V 走到 B
  3. V 指定 P 从左或右出现
  4. P 按照 V 要求从指定方向出现,如有必要,穿过 C、D 之间的门
  5. 重复步骤 1-4 n 次

若 P 不知开门方法,只有 1/2 机会猜中 V 的要求,执行 n 次,只有 \(2^{-n}\) 的机会完全猜中。若 n 足够大,几乎可以证明 P 是知道这个开门方法的,且 V 并没有得到任何关于这个方法的信息。

最早出现的零知识身份证明协议是 FFS(Feige-Fiat-Shamir)协议。

可信赖的第三方选定 \(m=p\times q\),p、q 为两个大素数,m 为 512bit 或 1024bit。通信双方共享 m,再由可信第三方实施公私钥分配,产生 k 个随机数 \(v_1,v_2,...,v_k\)(要求 \(v_i^{-1}mod\ m\) 存在,\(i=1,2,...,k\)),且使 \(v_i\) 为模 m 的平方剩余,即 \(x^2=v_i(mod\ m)\)\(v_i\) 为公钥,计算 \(s_i=\sqrt{v_i^{-1}} mod\ m\)\(s_i\) 作为示证方的私钥(P 为示证方,Q 为验证方)。

身份验证协议如下:

  1. 用户 P 取随机数 r(r<m),计算 \(x=(r^2)mod\ m\),讲 x 发送给 V
  2. V 发送挑战信息串 \(b_1,b_2,...,b_k\)\(b_i\) 为 0 或 1) 给 P
  3. P 接受挑战,算出 \(y=r\times \quad_{i=1}^{k}s_i^{b_i}mod\ m\) 作为应答发送给 V
  4. V 验证 P 的身份,验证 \(x=y^2 \quad_{i=1}^{k} v_i^{b_i}mod\ m\),如果相等则受骗概率为 \(2^{-k}\),若不相等验证过程终止

P 和 V 可以重复执行此协议,每次以不同的 r 和 b 串,执行一次验证过程后 P 能欺骗 V 的概率为 \(2^{-k}\)

FFS 协议经过多次交互才能保证身份认证的安全性,浪费系统资源且费时。

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×