网络名言：“你永远不知道网络的对面是一个人还是一条狗!”
因此要安全通信，首先你得知道对方是谁，其次才是对话内容的保密，否则就等于主动送上秘密，这是常识。
量子通信一直宣称在分发密钥中可以保证绝对的私密性，今天就信他们一回，让我们看看所谓“绝对私密的量子通信”放在真实的通信场境中倒底又是怎么回事。在量子通信开始时如果甲乙双方的真实身份无法确认，攻击者在通信线路中间对甲方冒充乙方，同时对乙方冒充甲方。甲方与攻击者之间、攻击者与乙方之间照样可以顺利分发得到二个密钥，然后甲方把通信内容加密后传送给了攻击者，攻击者用第一个密钥解密获得了全部通信内容，然后再把通信内容用第二个密钥加密后传送给乙方，乙方用密钥解密得到通信内容。甲乙双方还以为依靠量子通信完成了绝对安全的通信，谁知攻击者在暗处偷笑:量子通信传递的秘密“尽入吾彀中矣。”
以上就是典型的“中间人攻击”实例，由此可知，通信的安全性有着比私密性更高更强的要求，它不仅要求通信双方传送的内容不能被任何第三者知道，还要确认收发方各自的真实身份，还必须确认通信内容的完整性和不可篡改性，另外还要保证通信的稳定性和可靠性。
密码学界通常会用 “CIA ” 来概括通信安全的三要素：Confidentiality 私密性，Integrity 完整性，Availability 可利用性。所以通信过程仅有私密性是远远不够的，没有通信的完整性和不可篡改性，就免谈通信的安全性。
怎样才能保证通信的完整性和不可篡改性呢？让我们看看传统密码系统是如何工作的。
发信者Bob首次生成公钥和私钥，通过互联网把公钥上传到一个公共服务器上；
Bob对需要送出的文件执行哈希算法，得到哈希值（又称摘要）；
Bob使用加密算法生成数字签名，加密算法的输入有两个，一个是私钥，另一个是被签署文件的哈希值，输出的一个字符串就是数字签名；
Bob把文件和数字签名一起通过互联网递送给Alice。
收信者Alice收到文件和数字签名，并从公共服务器下载Bob的公钥；
Alice使用Bob的公钥对数字签名执行解密算法，得到原文的哈希值；
Alice对收到的文件执行相同的哈希算法得到新的哈希值；
Alice对比二个哈希值，如果它们完全相同就证明文件确是Bob发出，而且文件传递过程中没有被篡改过[1]。
以上就是Bob把带有数字签名的文件传递给Alice的全过程。但是这里存在一个明显的安全漏洞，因为Alice无法确认下载的公钥是否真的来自Bob，这就为“中间人攻击”提供了可能。假设在Bob的文件还没有到达Alice之前，黑客删除Bob的文件，然后用他的私钥签署一个假文件发送给Alice，黑客又在公共服务器上用他自己的公钥替换Bob的公钥。Alice下载了黑客的公钥，用黑客公钥验证黑客的签名当然不会有问题，她自认为文件就是Bob发出的，其实上当受骗了。这里的关键就在于Alice无法确认收到的公钥是否确实属于Bob，数字签名的本身无法保证文件发送者与公钥的所有者是同一个人。
要避免中间人攻击，可以使用数字证书，它的作用就是认证所有人和公钥的关系。数字证书是一个由可信的第三方发出的一个数字文件，用来证明所有人身份以及所有人拥有某个公钥。
典型的数字证书中至少包含以下四项内容：第一项是发证机构(CA)的名称；第二项是所有人姓名，例如Bob；第三项是所有人的公钥，以及公钥的有效时期；第四项就是CA的数字签名。
数字签名是CA发出的，而CA是有公信力的机构，他们的公钥是全网皆知。数字证书上同时带有所有人信息和公钥，并有CA的数字签名，只要用CA的公钥即可确定证书是否被篡改过。所以只要信任CA ，就可以信任所有人和公钥之间的绑定关系。
数字证书就是第三方机构发行的证书，它用自己的信用为数字证书做了背书，主要作用就是证明你的公钥的确是属于你的，而公钥其实就是我们在数字世界的身份，所以说数字证书的作用实际上就是证明你是你自己。
Bob有了自己的数字证书后，当他向网上的公共服务器传送公钥时会附上证书。Alice收到证书之后，使用CA的公钥对证书上CA的数字签名解密就可鉴定数字证书的完整性和不可篡改性。换言之，Alice有了数字证书就可以确认收到的公钥是否属于Bob的，接下来她可以放心使用Bob的公钥去验证Bob送来文件上的数字签名。只要数字签名没问题，就能证明Bob送来的文件是完整而且未被篡改过。
为了加深对数字证书的理解，我们将对HTTPS工作原理作详细的剖析。HTTPS就是安全的HTTP的意思，这是用在浏览器和服务器之间通信的协议。使用HTTPS后，浏览器跟服务器之间所有的通信内容都是加密过的。这个过程中的主角就是SSL证书，SSL证书就是用于HTTPS场境中的一种数字证书，它也是由可信的第三方CA 来颁发。只不过 SSL验证的不是个人的身份，而是用来验证服务器身份和它持有的公钥，目的就是建立浏览器和服务器之间的信任。
比如浏览器现在要访问百度服务器。浏览器首先要获取百度服务器的公钥，为了保证传递过来的公钥确实属于百度的服务器并且没有被篡改过，百度需要先去CA机构申请SSL证书，并把它放到自己的服务器上。当浏览器中输入百度的网址，百度服务器会首先给浏览器发送SSL证书。因为所有浏览器中都内置了全球各大CA机构的公钥，可以立即验证SSL上CA的数字签名。如果证书没有问题，浏览器就可以断定证书中携带过来的公钥就是百度的。这时候浏览器会生成一个隨机数作为对称加密用的密钥，然后用百度的公钥加密后将密文发送给百度服务器。百度服务器收到密文后用自己的私钥解密得到密钥。通过这个过程，百度服务器与浏览器之间就拥有了共享的密钥，接下来就可以用对称加密方式跟浏览器通信了。
从上面分析可知，数字证书其实就是数字签名的一个特殊应用，它通过具有公信力的第三方的数字签名把公钥和公钥所有人的身份捆绑在一起。通过数字证书和数字签名的结合使用方能保证文件传送过程中的不可扺赖性和不可篡改性，彻底杜绝“中间人攻击”，无此就谈不上什么通信安全。
加密通信和数字签名用的都是公钥加密技术。加密通信是用公钥进行加密，而用私钥进行解密；而数字签名刚好相反，是采用私钥加密，公钥解密。数字签名过程跟加密通信有着一定的对称性，这种对称性透着一种逻辑的美感。
公钥加密技术由于巧妙地运用了“公钥”和“私钥”这样一对密钥，为通信过程中的身份认证和数字签名提供了灵活有效的解决方案，而使用一个共享密钥的对称加密技术是完全无能为力的。虽然理论上对称加密技术在某些特定场合也可提供身份认证的功能，但是在今天的互联网通信环境中，使用对称加密技术作身份认证和数字签名是不可想像的。
所谓的量子通信(QKD)只能分发一个共享密钥，它其实只是对称加密技术中的一个子功能，因此QKD完全不具备为互联网提供切实有效的身份认证和数字签名的能力。量子通信用物理原理依靠硬件偏面追求通信的私密性，误以为通信的私密性就等于通信的安全性（其实QKD在私密性方面也是有争议的[2]），从一开始就走入了歧途把自己带入了深坑中。
因为量子通信缺失身份认证和数字签名功能，所以量子通信在密钥分发时为了防御“中间人”攻击，在它的量子通道和传统检验通道上都必须依赖传统密码的身份认证功能。被吹嘘得神乎其神的量子通信其实更像是泥菩萨过河—自身难保，量子通信连自身的安全都难保，竟然奢谈为高端客户提供绝对通信安全，实在令人啼笑皆非。
更可悲的是量子通信这个泥菩萨要过河，传统密码技术恐怕也救不了它。因为量子通信QKD分发密钥是一个时间很长的连续过程，而“中间人攻击”可能隨时隨地发生，在这种状况下，无论用何种方法作严格的身份认证都是不可完成的任务[3]。
2020年3月24日，隶属于英国情报部门的国家网络安全中心(NCSC)发布了一份白皮书[4]。该白皮书明确否定了量子通信QKD的实用价值，否定的理由就在“身份认证”这个关键问题上，原文照译如下。
“鉴于QKD在传统加密密钥协商机制上需要添置特殊硬件，而且又需要进行额外的身份认证，因此NCSC不赞成在任何政府或军事机构中使用QKD，并告诫不要在重要的商业通信网络依赖于QKD，尤其是在关键的国家基础设施领域。”
不愧是老谋深算大英帝国情报机构，他们对密码系统的评估独具慧眼值得引起业界高度重视。如果说，QKD的成码率低效率太差、不能与互联网兼容、可信中继站存在严重安全隐患这三大技术困境就像三座高不可攀的大山[5]，那么缺失身份认证机制无法扺御“中间人攻击”就是一条深不可测的鸿沟，它们都是量子通信工程化道路上难以逾越的技术障碍。
这里需要特别强调，QKD所面临的这四大技术困境是被物理原理所决定了的，单靠工程技术的进步是极难取得实质性的改变。残酷的现实是，目前要解决这四大技术困境连纸上的方案都没有，量子通信的工程化不具备最起码的可行性，盲目建成的量子通信工程项目就不可能有任何经济效益。总之，理论很美妙现实很骨感，美丽的花朵不一定结果的。
[1]本文为了把数字签名的原理说清楚，文件以明文方式直接传递。在许多应用场景中需要对文件加密后传递，但是数字签名的原理和方法是相同的，只需添加以下几个步骤即可：
Bob随机产生一个加密密钥，并用此密钥对要发送的文件进行对称加密，形成密文；
Bob用Alice的公钥对刚才随机产生的加密密钥进行加密，将加密后的密钥连同密文一起传送给Alice；
Alice收到Bob传送来的密文和加密过的密钥，先用自己的私钥对加密的密钥进行解密，得到Bob随机产生的加密密钥；
Alice然后用随机密钥对收到的密文进行解密，得到文件的明文格式，然后将随机密钥抛弃；
[2] 量子通信神话之一：量子通信在理论上是无条件安全的
https://zhuanlan.zhihu.com/p/87875706
[3]Actually the agent authentication problem against man-in-the-middle attack has not been dealt with seriously in QKD as far as I know. It is not so simple because one needs re-authentication during protocol execution. How does one get the shared secret key bits for such authentication in an ongoing process? The "practical" QKD people throw in lots of shared key bits, from PRNG also. （摘自 Prof. Horace Yuen 的电子邮件）
[4]否决量子通信工程 英国情报部门再发白皮书
https://www.ncsc.gov.uk/whitepaper/quantum-security-technologies
[5]量子通信三大技术困境
https://zhuanlan.zhihu.com/p/85323744
https://zhuanlan.zhihu.com/p/85930732
https://zhuanlan.zhihu.com/p/86896032
