阅读《Network Security Private Communication in a Public World》笔记

定义

Authentication is the process of reliably verifying the identity of someone (or something)

类型

password-based - what you know

密码是明文传输的。加密不是更安全吗,为什么不做这件事儿呢?

有些协议最初是为了human-computer protocol设计的,后来扩展到计算机之间的通信后并未重新设计;

有的协议设计者认为加密技术在实现时间或处理资源上的成本过高;

有的因为法律问题;


Off-vs On-line Password Guessing 字典攻击 /设定最多输错次数


密码的存储:分布式存储 or authentication storage node or authentication facilitator node

存储密码的 hash 值 or 加密值(更安全)

address-based - where you are

不依赖于在网络上发送密码,而是假设可以根据数据包到达的网络地址来推断源的身份。

e.g. in UNIX

/etc/hosts.equiv - contains list of computers that have identical user account assignments.

.rhosts - in a user’s home directory, contains a list of tuples <computer, account> that are granted access to this user’s account

To prevent users from granting access to others a centrally managed proxy database may be installed instead.

为了防止用户授予其他人访问权限,一个中性化管理的代理数据库会被事先安装。

《鸟哥的 Linux私房菜》中《第十一章、远端连线伺服器SSH / XDMCP / VNC / RDP》有介绍:

可见,尽管这种方法能抵御窃听,但它也不安全。试想一下,如果一个攻击者能伪造网络地址(very easy on broadcast LAN, more difficult in point-to-point networks),那就能任意访问资源了。

cryptographic-based

密码是加密处理后传输的。

Trusted Intermediaries

背景:如果每两个节点间通信都需要一对密钥,如果一个网络中加入了一个新节点,则需要生成n对密钥,其中n为原来的节点数。每一个节点都在本地存储和其它节点通信对密钥在目前的互联网下是不现实的,所以就有了一些替代方案。

key distribution 问题分为两类: Conventional (Secret) key distribution 和 Public key distribution,解决方法分别对应 KDC 和 AC

Key Distribution Center (KDC)

也叫 Trusted Third Part (TTP)

KDC知道每个节点的密码,如果一个新节点加入,只需要这个新节点和KDC配置一对密钥就行。

如果一个节点想和另一个节点通信,它会向KDC要一个temporary key (ticket)

KDC看起来很棒,但是它还是有弊端:

  1. KDC 是一个中心化的设计,包含了大量的信息,试想一下如果这些信息被盗用会发生什么?

  2. 由于其中心化的设计,会出现 a single point of failure,所以需要有故障的预防工作。

  3. 每个人都要与它通信,可能会导致 performance bottleneck

Q:实际的应用?

A:Kerberos认证 /Cisco GetVPN(被用于分发TEK - Traffic Encryption Key)… 来自知乎回答 秘钥分发中心(KDC)在实际应用中是不是使用的比较少? 生动形象地描述了用户如何和服务端建立连接

Certification Authorities (CAs)

Key distribution is easier with public key cryptography.

Each node knows its own private key, and the public keys can be obtained from a central entity.

Q: 怎么保证公钥是正确的,没有被篡改呢?

A: Establish a trusted node, a Certification Authority (CA), to generate certificates

证书(Certificates) = 公钥 + 申请者与颁发者信息 + 签名

具体流程:

书里的描述很简单,我很疑惑如果CA的private key被泄露了,那该怎么办?实际的做法也是简单粗暴,直接该用该密钥签署的所有证书都无效,全部吊销,CA会生成新的私钥并重新签署之前的证书。

如果密钥丢失CA不立刻行动,会使得CA信誉损失进而倒闭,如diginotar

看起来CAs需要好好保管它们的私钥,该怎么做呢?请看这里

第一个回答太有趣了:

Initial setup of a serious root CA involves a Key Ceremony with herds of auditors with prying eyes, and a formalism which would not have been scorned by a Chinese Emperor from the Song dynasty.

回答还提到最weak的CA一般来自于国家控制的根CA,某些国家在对待密钥的管理上没有那么serious,然而像微软这类公司若想要在这些国家做生意,必须要信任这些根CA。

那CA相对于KDC的好处是什么?

  1. 不需要 on-line,因为这点,同时带来更多好处:

a. a comparably simple device can be emloyed,从而提高安全性

b. 如果 CA crashes 了,我们还能使用它;只有新用户不行

  1. not security-sensitive

  2. 被盗用的 CA 不能继续使用

Certificate Revocation

  • Publish a list named Certificate Revocation List (CRL)
  • The CRLs will be distributed periodically or after a new version to all computers.

Multiple Trusted Intermediaries

KDCs 和 ACs 都有一个问题,only one single entity,在这个系统中的节点必须选择信任它,但是建立一个全世界所有人都信任 entity 是困难的,解决方法就是 subdivide the world into domains with a trusted entity (KDC or CA) for each such domain

A global network comprises of thousands of domains

如果每对KDC都要share一个key,那就太复杂了,解决办法就是使用树的结构或是使得KDC之间连接更少的结构。

对于AC也说亦是如此。

Session Key Establishment

从理论上讲,在Alice和Bob之间的对话中,Alice可以使用Bob的公共密钥(为了保护隐私)对发送给Bob的所有数据进行加密,并使用自己的私有密钥对每个消息进行签名(以确保完整性)。 Bob也类似。

但通常现实中不会这样做,因为基于公钥的加密解密在计算上很复杂,实际的做法是:

have principals to agree on a secret key, and to protect the remainder of the conversation with this key. The authentication protocol should help the principals agree on a secret key

Suppose Alice and Bob are using a shared secret key for authentication. They could continue to use that key to protect their conversation. However, it is a good idea to generate a separate session key

Access Control

除了验证who you are这个问题外,authentication还包括了what you are allowed to do.

方法:

  • An ACL (access control list) 存储每个人对,每种资源的访问权限;但如果user group很大的话,维护这样一个list会很麻烦
  • 一种解决方法是引入groups的概念,但这个又导致了一个问题:efforts may duplicated if different groups exist with identical membership
  • 解决duplication effort的方法是:

    • Store the group-list at a central server -> bottleneck
    • Include information about to which groups an individual belongs into that individual‘s certificate (in case of public key based schemes) or into his ticket (in the case of a secret key KDC based scheme) -> an individual‘s certificate may become very large
  • Hierarchical groups:

    • It is more flexible, convenient, and scalable if recursive group membership is possible.
    • Management becomes easier.
    • Problem: groups will be administrated on different servers. Authorization depends on server availability.

Delegation

有时候你需要授予别人访问你的资源的权限,这个过程叫做 delegation or authentication forwarding

授权的方法是 generate a special message(权限授予谁?什么权限?持续多久?), signed by the authorized user

Authentication of People

三种方法:

  • Something you know(password)
  • Something you have(physical keys)
  • Something you are (biometric devices)

some details

PIN-, PW-, Biometric-based schemes

  • Kerberos 麻省理工学院开发的安全认证系统
  • SecureID tokens
  • Iris/retina scanners 虹膜/视网膜扫描仪
  • Thumbprint & hand/palmprint 拇指指纹/掌纹和手
  • Handwriting acceleration & pressure 测量笔迹加速度和压力

分析每种方式的优点和局限性

  • Human Failings / Biometrics / Fingerprints / Voice Recognition
  • Keystroke Timing(Best done for “local” authentication - Avoid network traffic delay)
  • (Non-digital) Signatures (还可以加入写字时的压力和速度)
  • SecureID/Secure-Token (TTP/Server: secure & knows all secrets!)

Authentication Protocols

During the handshake phase communication parameters are negotiated and initial information are exchanged. Some of these information are secret (e.g. the password), some are not (e.g. the user names).

e.g. a protocol such as is used when a person logs into a system such as UNIX

其中Bob(认证用户方)存储了Alice密码的哈希值。

Protocol ap1.0: Alice says “I am Alice” (坏人可以直接充当 Alice)

Protocol ap2.0: Alice says “I am Alice” in an IP packet containing her source IP address (坏人可以创建一个包含 Alice 地址的包 “spoofing”)

Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it (playback attack: Eve records Alice’s packet and later plays it back to Bob)

Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it(record and playback still works!)

Protocol ap4.0: to prove Alice “live”, Bob sends Alice nonce (a number used once ®), R. Alice must return R, encrypted with shared secret key. K may be derived from Alice’s password … This protocol works if Bob never authenticates to Alice using K

Protocol ap5.0: nonces and public key cryptography. Using PKA, Bob verifies Alice’s signature of R in msg3. Since R is fresh and only Alice can compute signatures using SKA, Bob concludes that Alice is really there.

Nonce-Types

A nonce is a quantity which any given user of a protocol uses only once. Many protocols deploy nonces, and there are different types with different sorts of properties.

分为 Random number、Sequence number、Timestamp 三类

e.g. 有关包含 nonce 的协议

为什么要加入 ||B 呢?