AES 和 RSA 笔记 的续章。
Scenario 1 (Like WWII 和 TEA)
- 双方共享一把密钥。
- A 用密钥对信息加密。 E(KAB,Mi) ，发送给 B
- B 用 D(KAB,MiKAB) 解密读取信息。
问题是：
双方如何同步密钥？
怎么确定 B 收到的 MiKAB 不是 replay of an old message?
Scenario 2 (Like Kerberos)
- A 向第三方 S 索要一张和 B 通话的 ticket。
- S 知道 A 的 password 所以他可以计算 KA
- S 发送给 A { { Ticket}KB,KAB},KA
- A 知道自己的 password 所以可以计算 KA ，注意 A 的 password 不会在网络中传输。
- A 可以计算出 KAB 和 { Ticket}KB
- A 向 B 发送一个读的请求，发送的信息是 { Ticket}KB ,Alice,Read
- B 用 KB 来读取 Ticket 的内容，Ticket 的内容是 KAB ，Alice
- A、B 可以用 session key 来交流了。
可以防止 replay，但 问题是:
- 难以 scale,S 必须知道 KA , KB ,…
- S 是唯一可能导致失败的因素。
Kerberos 这一名词来源于希腊神话“三个头的狗——地狱之门守护者”系统设计上采用客户端/服务器结构与DES加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止 repla y攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。
Needham-Schroeder protocol
这层协议是 Kerberos 的基础，在这之后，Alice and Bob share a secret (KAB)
Scenario 3 (Authentication)
- A 发送 Message＋用密钥加密的 Message 的 digest。{Digest(M)} KApriv
- B 收到签名的文件，取出 Message，计算 Message 的 digest。
- B 用 A 的公钥 KApub 解密 {Digest(M)} KApriv 然后和自己算的 digest 比较，如果匹配，签名验证。
问题：
如果 A 说他没有签名？说自己的私钥泄漏了？只要 A、B 互相信任，还是有用的。
Scenario 4 (Like SSL)
- A 和 B 想要建立一个共享的密钥
- A 拿到 B 的公钥，这个公钥被可信任的第三方 T 签名认证了，所以这个公钥确实是 B 的。
- A 确认第三方 T 对 KBpub 签名了。怎么确认？A 和 T 都有 B 的 public key，T 把 KBpub 加密后给 A，A 对其进行解密然后比对自己手上的 B 的 public key 看是不是一致。
- A 生成了 KAB 并用 KBpub 加密。
- B 有很多公钥所以 A 发送公钥的名字。
- A 发送了 key name { KAB}KBpub
- B 用这个 key name 选择了对应的私钥并计算 { { KAB}KBpub}KBpriv==KAB
最后 A 和 B 共享了对称的钥匙 KAB
问题：
在 A 第一次得到 B 的公钥时（A 认为这是 B 的公钥，然而这并不是，这是 C 也经过第三方 T 签名认证的公钥。
TLS 和这个相似
Message Authentication Codes(MACs)
用于数字签名，双方都算了一遍 MAC
JAVA 里的 keystore 和 truststore
keystore: 存了公钥、私钥、证书
truststore：存了公钥，只能存 server 发过来的东西
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/129924.html