RSA、Diffie-Hellman和中间人攻击

网络上常常有对RSA、DH算法，以及中间人攻击的讨论。

一种说法是“RSA密钥协商（交换）不会受到中间人攻击”，听起来似乎RSA比DH做密钥协商更优。

这种说法有些不负责任。下面把这个问题中涉及到的概念都解释一下，再来看这个问题。

中间人攻击，可以这样解释：攻击者一定程度上控制了网络，成为网络双方通信的中间者，从而获取到双方的通信信息；而通信双方都感知不到中间人的存在。

这个话题往往和加密通信一起讨论：如果加密信道中存在中间人，那明文就会被中间人获取，而通信双方还不会知晓。

中间人攻击的根本，在于通信双方没有进行身份认证。即：不知道和自己直接通信的人是谁。如果双方能确认直接通信的人就是对方，也就不存在中间人攻击了。

RSA加密算法 是一种非对称加密技术。由一对密钥（公钥+私钥）组成。

可以利用私钥来生成公钥。

一般来说，私钥会被秘密保存起来，而公钥则分发出去。

公钥加密，私钥解密，称为RSA加密算法。 是为了保证公钥加密的内容，只有私钥持有者可以解密。常常用在客户端账密登录过程：客户端对密码进行公钥加密，发送到服务端后用私钥解密，这样即使请求被截获也不会泄露密码（实际上要更复杂一些）。

私钥加密，公钥解密，称为RSA签名算法。 是为了保证公钥持有者获取的内容，确实是来自私钥持有者的正确内容。比如服务器持有私钥，将一个重要信息计算hash再私钥签名后，和信息本身一起发送到客户端；客户端用公钥解密签名得到hash值，再计算信息的hash值，进行比对，就知道内容是否被篡改。由于私钥的保密性，攻击者无法伪造有效的签名。

DH密钥交换算法 并不是 加密算法，而是双方在不安全的网络中交换信息而生成双方仅有的密钥的一种方法。其结果是，交换的双方得到了一样的会话密钥，而其他任何人不能得到这个密钥。

由于算法的结果是通信双方拥有了一样的密钥，双方往往会利用这个密钥进行 对称 加密通信。

DH算法的过程可以简单解释如下：通信双方AB，各自生成一对DH密钥(Pa,Sa)和(Pb,Sb)（P代表公钥，S代表私钥）。双方交换各自的公钥P，于是A持有Sa、Pb，B持有Sb、Pa。通过某种计算，Sa、Pb可以生成会话密钥K，Sb、Pa也可以生成相同的K。

DH算法本身不包含身份认证机制，所以中间人攻击是其明显的问题。

设想：

在AB间，有一C。AB交换DH公钥P时，C在中间截获；C自己生成一对DH密钥(Pc,Sc)，用Pc和A、B完成密钥交换。于是C与A间有了会话密钥Kac=f(Pa,Sc)=f(Pc, Sa)，C与B间有了会话密钥Kcb=f(Pb,Sc)=f(Pc, Sb)。只要C从一方获得的信息，重新加密后传递给另一方，AB就都不会发现他们的通信被劫持了。

密钥协商(key establishment)包括“密钥传输”(key transmission)和“密钥交换”(key exchange)。

所谓RSA密钥协商实际是密钥传输，即一方生成密钥，传递给另一方，而不必双方交换。

具体来说，就是A自己生成一个密钥K，用自己的RSA公钥加密，再传递给B；B用RSA私钥解密得到K。仅就这个过程而言，不会存在中间人攻击。

但是这不是说RSA就比DH就更安全了。设想上面的情况，必须先要令A持有RSA公钥，B持有RSA私钥。这首先先进行一次RSA公钥传递，而这个传递过程是存在中间人攻击的。

设想：

B生成一对RSA密钥Pb、Sb，将公钥Pb发送给A。而AB中有C。C截获了Pb，而自己生成了一对RSA密钥Pc、Sc，将Pc发送给A。

A用Pc加密了会话密钥K，发送给B，被C截获。C用Sc解密得到K，再用Pb加密后给B。这时C完成了中间人攻击。

所以说： RSA的公钥在端与端间传递时，存在中间人攻击问题。

RSA最好的使用场景在服务端/客户端之间，服务端持有私钥，客户端直接内置好公钥，就不用担心中间人攻击了。

平时我们使用的，号称安全的https协议，也存在中间人攻击问题。比如Fiddler这种抓包软件，就能充当https通信中的中间人。

一般上网时使用的https是 单向认证 ，即客户端通过CA认证服务器持有有效证书，来确认其身份。服务器不会验证客户端的身份。

如果使用 双向认证 ，通过CA确认两端的身份都是正确的，就可以防止中间人攻击了。这种双向认证一般出现在企业应用对接中。

网络上有这样一种说法：

通信两端交换RSA公钥，通过对方公钥加密数据，自己私钥解密。这样就实现了端到端加密。

实际上这 不是端到端加密 。因为不能保证服务器无法修改数据：服务器可以用公钥来加密任何的数据发给两端。

而且，按之前所说的，这种交换， 存在中间人攻击问题 。

常见密码算法原理

PBKDF2(Password-Based Key Derivation Function)是一个用来导出密钥的函数，用来生成加密的密码，增加破解的难度，类似bcrypt/scrypt等，可以用来进行密码或者口令的加密存储。主要是盐值+pwd，经过多轮HMAC算法的计算，产生的密文。

PBKDF2函数的定义

DK = PBKDF2(PRF, Password, Salt, c, dkLen)

• PRF是一个伪随机函数，例如HASH_HMAC函数，它会输出长度为hLen的结果。

• Password是用来生成密钥的原文密码。

• Salt是一个加密用的盐值。

• c是进行重复计算的次数。

• dkLen是期望得到的密钥的长度。

• DK是最后产生的密钥。

下面我们以Alice和Bob为例叙述Diffie-Hellman密钥交换的原理。

1,Diffie-Hellman交换过程中涉及到的所有参与者定义一个组，在这个组中定义一个大质数p，底数g。

2,Diffie-Hellman密钥交换是一个两部分的过程，Alice和Bob都需要一个私有的数字a，b。

下面是DH交换的过程图：

本图片来自wiki

下面我们进行一个实例

1.爱丽丝与鲍伯协定使用p=23以及g=5.

2.爱丽丝选择一个秘密整数a=6, 计算A = g^a mod p并发送给鲍伯。

A = 5^6 mod 23 = 8.

3.鲍伯选择一个秘密整数b=15, 计算B = g^b mod p并发送给爱丽丝。

B = 5^15 mod 23 = 19.

4.爱丽丝计算s = B a mod p

19^6 mod 23 = 2.

5.鲍伯计算s = A b mod p

8^15 mod 23 = 2.

ECDH:

ECC算法和DH结合使用，用于密钥磋商，这个密钥交换算法称为ECDH。交换双方可以在不共享任何秘密的情况下协商出一个密钥。ECC是建立在基于椭圆曲线的离散对数问题上的密码体制，给定椭圆曲线上的一个点P，一个整数k，求解Q=kP很容易；给定一个点P、Q，知道Q=kP，求整数k确是一个难题。ECDH即建立在此数学难题之上。密钥磋商过程：

假设密钥交换双方为Alice、Bob，其有共享曲线参数（椭圆曲线E、阶N、基点G）。

来自

exponent1 INTEGER, -- d mod (p-1)

exponent2 INTEGER, -- d mod (q-1)

coefficient INTEGER, -- (inverse of q) mod p

otherPrimeInfos OtherPrimeInfos OPTIONAL

}

-----END RSA PRIVATE KEY-----

while a RSA public key contains only the following data:

-----BEGIN RSA PUBLIC KEY-----

RSAPublicKey ::= SEQUENCE {

modulus INTEGER, -- n

publicExponent INTEGER -- e

}

-----END RSA PUBLIC KEY-----

and this explains why the private key block is larger.

Note that a more standard format for non-RSA public keys is

-----BEGIN PUBLIC KEY-----

PublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

PublicKey BIT STRING

}

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL

}

-----END PUBLIC KEY-----

More info here.

BTW, since you just posted a screenshot of the private key I strongly hope it was just for tests :)

密钥的长度

C:\herongjava RsaKeyGenerator 128

p: 17902136406704537069

q: 17902136406704537077

m: 320486487924256034368552058949822333168

Modulus: 320486487924256034404356331763231407313

Key size: 128

Public key: 138184930940463531660820083778072069237

Private key: 173448309040289888328993883042709949325

C:\herongjava RsaKeyGenerator 256

p: 248658744261550238073459677814507557459

q: 248658744261550238073459677814507557527

m: 618311710977310434529034534762836648859088873902738200302650613...

Modulus: 618311710977310434529034534762836648864062048787969205064...

Key size: 256

Public key: 394190853336940694532345943348534965939075733405768734...

Private key: 21429568381701961014089098585280129682302896350728470...

update() adds data to the Cipher’s internal buffer, then returns all currently completely encoded blocks. If there are any encoded blocks left over, they remain in the Cipher’s buffer until the next call, or a call to doFinal(). This means that if you call update() with a four byte array to encrypt, and the buffer size is eight bytes, you will not receive encoded data on the return (you’ll get a null instead). If your next call to update() passes five bytes of data in, you will get an 8 byte (the block size) array back, containing the four bytes passed in on the previous call, the first four bytes from the current call – the remaining byte from the current call is left in the Cipher’s buffer.

doFinal() on the other hand is much simpler: it encrypts the passed data, pads it out to the necessary length, and then returns it. The Cipher is essentially stateless.

来自

DH算法的中间人攻击

在最初的描述中，迪菲－赫尔曼密钥交换本身并没有提供通讯双方的身份验证服务，因此它很容易受到中间人攻击。 一个中间人在信道的中央进行两次迪菲－赫尔曼密钥交换，一次和Alice另一次和Bob，就能够成功的向Alice假装自己是Bob，反之亦然。而攻击者可以解密（读取和存储）任何一个人的信息并重新加密信息，然后传递给另一个人。因此通常都需要一个能够验证通讯双方身份的机制来防止这类攻击。

优缺点：

1、 仅当需要时才生成密钥，减小了将密钥存储很长一段时间而致使遭受攻击的机会。

2、 除对全局参数的约定外，密钥交换不需要事先存在的基础结构。

然而，该技术也存在许多不足：

1、 没有提供双方身份的任何信息。

2、 它是计算密集性的，因此容易遭受阻塞性攻击，即对手请求大量的密钥。受攻击者花费了相对多的计算资源来求解无用的幂系数而不是在做真正的工作。

3、 没办法防止重演攻击。

4、 容易遭受中间人的攻击。第三方C在和A通信时扮演B；和B通信时扮演A。A和B都与C协商了一个密钥，然后C就可以监听和传递通信量。中间人的攻击按如下进行：

（1） B在给A的报文中发送他的公开密钥。

（2） C截获并解析该报文。C将B的公开密钥保存下来并给A发送报文，该报文具有B的用户ID但使用C的公开密钥YC，仍按照好像是来自B的样子被发送出去。A收到C的报文后，将YC和B的用户ID存储在一块。类似地，C使用YC向B发送好像来自A的报文。

（3） B基于私有密钥XB和YC计算秘密密钥K1。A基于私有密钥XA和YC计算秘密密钥K2。C使用私有密钥XC和YB计算K1，并使用XC和YA计算K2。

（4） 从现在开始，C就可以转发A发给B的报文或转发B发给A的报文，在途中根据需要修改它们的密文。使得A和B都不知道他们在和C共享通信。

如何防范中间人攻击

中间人攻击英文名叫：Man-in-the-MiddleAttack，简称MITM攻击。指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

如何防范中间人攻击

1、使用HTTPS：确保您只访问那些使用着HTTPS的网站。HTTPS提供了额外的安全保护层。在此，您可以考虑下载并安装Electronic

Frontier Foundation的HTTPS Everywhere浏览器扩展程序。它是Google Chrome浏览器最好的隐私扩展程序之一。

2、不要忽略警告：如果您的浏览器提示，您正在访问的网站存在着安全问题，那么就请引起足够的重视。毕竟安全证书警告可以帮您直观地判定，您的登录凭据是否会被攻击者截获。

3、不要使用公共WiFi：如果您无法避免使用公共WiFi，那么请下载并安装安全防护，为连接增加安全性。同时，在使用公共WiFi连接时，请留意浏览器的安全警告。如果警告的数量突然猛增，那么很可能就表明某个漏洞遭到了中间人攻击。

4、运行并更新防病毒软件：除了此外，也请考虑使用诸如Malwarebytes Premium之类的其他安全工具。