『漫游』酷论坛>『eDonkey交流区』>ED精華區>精華中的精華>[转贴]身份认证原理介 ..

[转贴]身份认证原理介绍

zhouwei_e@2004-12-23 00:56

身份认证原理介绍


================================================================

目录:
1. 前言
2. 身份认证的由来
3. 非对称加密技术
3.1 加密与解密的钥匙
3.2 公钥与私钥
4. 身份认证的过程
4.1 私钥生成
4.2 初相遇
4.3 再相遇
5. 认证过程总结
6. 身份认证的安全性

----------------------------------------------------------------

1. 前言


如果你还不知道电骡的身份认证功能, 请看电骡设置中的 选项 -> 安全
-> 使用安全认证 这里是否打上了勾. 默认地, 电骡使用安全认证. 这里
的 "安全认证" 即是本文要介绍的 "身份认证".

本论坛已经有一篇介绍身份认证的文章:
安全用户认证原理
这篇文章是直接引用了电骡官方网站上对安全认证的解释. 这段解释很粗
略, 使得不了解身份认证又想知道其原理的人仍很迷惑. 相比之下, 本文
将比较详细地介绍身份认证的原理, 希望能为一些骡友解惑.

本文涉及一些比较专业的领域, 讲起来可能会不够清晰直白, 希望广大骡
友多提意见. 也请专业人士批评指正本文的不当之处, 先行谢过.

----------------------------------------------------------------

2. 身份认证的由来


为了奖励那些努力上传的用户, 电骡有一套信用系统, 来记录每个用户的
上传和下载情况. 要为每个用户做信用记录, 一个前提条件是, 电骡必须
能够对不同的用户进行区分和识别. 如何对每个用户进行识别呢? 每个用
户必须拥有一个独一无二的标识, 并且要保证该标识无法被其他人冒充.
这个独一无二的标识即是电骡的 UserHash, 它是在电骡第一次运行时随
机生成的, 保存于 preferences.dat 文件中. 这个 UserHash 就好比我
们的身份证一样, 是要向别人出示的. 现在, 必须想办法使其他人无法伪
造一份相同的 UserHash. 由于在计算机里复制一段内容是十分容易的,
UserHash 本身是可以任意复制的, 比如, 可以将 preferences.dat 文件
复制多份, 也可以在网络路由器上偷听电骡间的会话过程而截取
UserHash 值. 现在, 如果有办法使那些复制的 UserHash 无效, 就能达
到防伪的目的了. 这如何做到呢? 在身份认证的过程中, 用一个保密的私
钥来使复制品无效. 私钥相当于 UserHash 的防伪标志, 私钥是保密的.
在介绍身份认证的过程前, 需要先介绍与私钥密切相关的 非对称加密技
术.

----------------------------------------------------------------

3. 非对称加密技术(Asymmetric Cryptography)


3.1 加密与解密的钥匙(Key)

实现数据加密时需要三个因素: 待加密的数据, 钥匙(Key), 加密算法.
加密时, 按照加密算法, 用 加密钥匙 把 待加密数据 转换成 已加密的
数据. 解密时, 用 解密钥匙 把 已加密的数据 还原成 待加密的数据.

在加密算法中, 如果 加密钥匙 与 解密钥匙 相同, 则称为 对称加密;
如果 加密钥匙 与 解密钥匙 不相同, 则称为 非对称加密.


对称加密 是容易实现的, 有很多种对称加密算法; 非对称加密的算法比
对称加密要复杂得多, 现有的非对称加密算法也很少, 目前通用的非对
称加密算法是 RSA 算法. 电骡采用这种算法.

3.2 公钥(public key) 与 私钥(private/secret key)

公钥是需要发送给对方的; 私钥是需要保密的, 不能给任何人. 用公钥加
密后的数据, 可以用私钥解密, 反之亦然. 公钥 与 私钥 是紧密相关的,
从 私钥 可以容易地算出 公钥, 但从 公钥 无法算出 私钥.


----------------------------------------------------------------

4. 身份认证的过程


认证过程的细节可能会有一些出入, 但原理是相同的. 为了方便总结, 在
下面的过程叙述中采用了很多符号化表示方法, 这里解释如下:

skA : A 的私钥(secret key of A)
skB : B 的私钥
pkA : A 的公钥(public key of A)
pkB : B 的公钥
m == n : "==" 表示 m 与 n 相等
skA{ 数据 } : 用 skA 将数据加/解密
pkA{ 数据 } : 用 pkA 将数据加/解密
*** 提示 *** : 数据 == skA{ pkA{数据} } == pkA{ skA{数据} }
Na : A 生成的随机数
Nb : B 生成的随机数
数据
A -------> B : A 通过网络将数据传输给 B
数据' : 一撇 "'" 表示数据是从网络上收到的, 还未证明真实性.
公式 => 结果 : "=>" 表示得出结果.

4.1 私钥的生成

当第一次开启电骡的身份认证功能时, 电骡会生成一个384位(Bit)的RSA
私钥(以下简称"私钥"). 生成的私钥保存于 cryptkey.dat 文件中. 公钥
并不需要特别保存, 因为可以根据需要随时由私钥算出公钥.

4.2 初相遇

两个电骡 A 与 B 第一次相遇时:

4.2.1

A 生成一个随机数, 将随机数和自己的公钥发给 B ; B 也生成一个随机
数, 连同 B 的公钥发给 A. 符号化如下:

引用
pkA, Na pkB, Nb
A -----------> B B -----------> A


之后, 双方互相证明身份. 由于证明过程相同, 以下只写出 A 向 B 证明
身份的过程, 如下:

4.2.2

A 用自己的私钥将 B 的公钥与 B 的随机数加密, 加密的结果发给 B.

引用
skA{ pkB', Nb'}
A -------------------> B


4.2.3

B 用 A 的公钥将 A 发来的加密结果解密, 并与自己的公钥及之前发出的
随机数对照, 若相符, 则 A 通过认证.

引用
pkA{ skA{ pkB', Nb'}' } => pkB', Nb'
若 pkB', Nb' == pkB, Nb 则认证通过


4.2.4

若 A 通过认证, 则 B 将 A 的 UserHash 与公钥保存到自己的
clients.met 文件中. 同理, 若 B 通过认证, A 也将 B 的 UserHash
和公钥保存到自己的 clients.met 中.

4.3 再相遇

当 A 与 B 再次相遇, 互相认证身份. 以下只叙述 A 向 B 证明身份的过
程.

4.3.1

B 新生成一个随机数, 发给 A.

引用
Nb
B ----------> A


4.3.2

A 从自己的 clients.met 中找出 B 的公钥, 然后用自己的私钥将 B 的
公钥与 B 发来的随机数一同加密, 将加密结果发给 B.

引用
skA{ pkB, Nb' }
A ---------------------> B


4.3.3

B 从自己的 clients.met 中找出 A 的公钥, 将收到的加密结果解密, 并
与自己的公钥及先前发出的随机数对照. 若符合, 则 A 通过认证.

引用
pkA{ skA{ pkB, Nb'}' } => pkB', Nb'
若 pkB', Nb' == pkB, Nb 则认证通过


----------------------------------------------------------------

5. 认证过程的总结

可以注意到, 第一次相遇与再相遇, 其认证过程是十分相似的, 我们可以
把第一次相遇时互换公钥的事件抛开, 抓住认证过程的本质, 将 A 向 B
证明身份的过程总结如下:

5.1

引用
B:
Nb
B --------> A


5.2

引用
A:
skA{ pkB, Nb' }
A ---------------------> B


5.3

引用
B:
pkA{ skA{ pkB, Nb' }' } => pkB', Nb'
若 pkB', Nb' == pkB, Nb 则 A 通过认证.


----------------------------------------------------------------

6. 身份认证的安全性

现在我们来讨论, 是否有人(设为C)能冒充 A 并骗取 B 的信任. 在 5.1
里, 若 Nb 被更改, 则 5.3 中 Nb' 无法与 Nb 匹配. 在 5.2 里, 由于
C 不知道 skA 的值, 即使 C 用 pkA 将 skA{ pkB, Nb' } 解密, 他也无
法伪造一份 skA{} 出来; 如果 skA{ pkB, Nb' } 被更改, 则 5.3 中无
法用 pkA 将其解密或解密结果与 pkB, Nb 不匹配.

可见, 不可能有人冒充 A. 究其根本, 是因为除 A 外, 没人拥有 A 的私
钥.

随机数 Na Nb 的作用: 假设没有 Nb, 则 skA{ pkB, Nb } 退化为
skA{ pkB }, 那么, 虽然 C 不能更改 skA{ pkB }, 但 C 可以复制一份
skA{ pkB } 来骗取 B 的信任. 随机数的作用就是保证 A 能将任何数据
用正确的私钥来加密
. 注意每次认证时都要重新选取随机数.

我们把将验证数据经私钥加密后的结果称为 数字签名, 在上面的过程里,
Nb 是验证数据, skA{ pkB, Nb } 为 A 的数字签名. 由 RSA 算法和身份
认证过程可知, 数字签名无法伪造.

================================================================


Shane.G
2004年12月19日
引用

shinji@2004-12-23 01:07

好文章 支持一下 :)
引用

伯伯@2004-12-23 01:12

好复杂哦
引用

Sherry35@2004-12-23 02:09

收藏ing..
引用

adamhj@2004-12-23 10:37

这样说来……如果一方的clients.met文件丢失也会造成不能通过验证咯?
引用

zhouwei_e@2004-12-23 10:46

不会,只是见面时重新生成一个公钥而已~
引用

atkio@2004-12-23 10:58

缺少数字签名的介绍
引用

wxl_man@2004-12-23 11:05

很专业的说~~~
引用

luluking008@2004-12-23 18:26

哈哈~~看不懂,hehe~~
引用

ralphgu@2004-12-23 18:52

实在看不懂
引用

lejun@2004-12-23 18:59

弱弱的问,如何防止坏人C将文件拥有者A的请求在线转发给某无私上传者B,再将B的回复传给A以骗取积分?
引用

zhouwei_e@2004-12-23 20:19

??

没听明白,基本上开启安全认证基本就不用担心被人做手脚了,除非你的认证文件也被人复制过~
引用

wtw29@2004-12-24 00:50

这个要收藏
支持一下
引用

luker@2004-12-24 00:54

非对称加密 嗯 嗯 时下流行的东西

我当年可是用这个搞定过N多论文的 XD
引用

lejun@2004-12-24 16:09

引用
最初由 zhouwei_e 发布
??

没听明白,基本上开启安全认证基本就不用担心被人做手脚了,除非你的认证文件也被人复制过~


例如C要从A这里下东西,但是没有Credit...

Na
A --------> C

C: 你等会哦……
随便找一上传狂B,假装刚上来的样子:

C: 偶是A~~
Na
C --------> B

skB{ pkA, Na }
B ---------------------> C

然后C在B这里当然通不过啦,断开。

不过没关系,回去告诉A好了:
skB{ pkA, Na }
C ---------------------> A

成功偷到B的积分……

:confused:
引用

«123»共3页

| TOP