基于CPK认证技术的家居智能系统.doc

在智能家居系统中，以小米为主的各大智能家居厂商，在进行系统交互认证的时候，基本上都基于PKI认证体制，使用客户端和服务器证书的方式，进行双方身份的验证，来完成对双方通信的身份鉴别认证，交互后续数据加密的密钥，使用双方协商的密钥进行数据加密通信。在此种体制中，需要第三方CA认证中心的在线支持，而且不能实现离线认证，还有就是会存在中间人攻击，如果客户端和服务器出现漏洞，中间人攻击就会很容易的窃取到双方通信的机密数据，造成用户信息泄露等等风险。而基于CPK认证技术恰好可以解决PKI体制的缺点。基于CPK认证技术的系统框架原理：在服务器端，服务器保存客户端CPK标识的公钥矩阵，并利用椭圆曲线算法，随机生成另外一份公私钥对，保存在服务器端。服务器端接收客户端的登陆请求，产生随机数A，利用CPK标识认证技术，在服务器端保存的另外一份公私钥对中，生成随机数A的公私钥对，然后利用客户端的标识公钥加密随机数A的公私钥对，下发到客户端。客户端输入登陆的账号信息，使用下发到客户端的随机数A的标识公钥加密，上传到服务器端，服务器端验证客户端的账号信息，如果验证通过，此时服务器产生随机数B，利用随机数A的标识公钥加密传回客户端，此后，服务器和客户端之间的加密信息就用随机数B作为加密密钥，进行通信。 客户端 服务器客户登录请求下发随机数A的公私钥对客户端身份信息，用A的公钥加密身份信息验证通过，通知客户端状态下发随机数B，用A的公钥加密加密数据通信，使用B作为密钥上述交互流程风险分析：如果客户端和服务器端在进行通信的时候，有一个假冒的中间人，在客户端和服务器端进行数据劫持或者转发，能否泄露双方的机密信息。客户端假如叫做A，服务器端叫做B，窃听中间人叫做C。中间人C利用arp欺骗，或者dns劫持技术，分别维护A和B之间的连接，但是对于A和B来说，根本无法察觉到C是别和A和B之间进行连接。由于CPK标识认证技术，公钥矩阵可以公开，C就可以很容易的获取到标识的公钥矩阵，由于私钥矩阵采用USB-key的方式，C不能容易的获取到A和B的私钥。中间人C利用椭圆曲线算法，也随机生成一个公私钥对矩阵，保存在C中。中间人C冒充客户端A，发送登陆请求，服务器B下发随机数a的公私钥对，用A的公钥加密信息，下发到A中，但是由于中间人的存在，首先到达了中间人C，由于C没有获取到A的私钥，所以C无法拆看到B下发给A的随机数a的公私钥对。C只能使用其他手段破解A的私钥，由于破解A的私钥，在计算理论上是不可行的方式。中间人C冒充服务端B，客户端A发送登陆请求，到达C处，C随机产生随机数a，并用A的公钥加密随机数a的公私钥对，下发的随机数a公私钥对到达A后，A以为是从真正的服务器B发送过来的，于是A用随机数的a的公钥加密后续验证信息，发送给服务器B，被中间人C劫持，由于随机数a的公私钥对是由C产生的，所以C可以拆看到A发送给B的信息，这样A的一部分信息就暴露在了C面前。C就获取到了A的客户信息之类的东西。通过上述的简要描述，可知中间人C可以很容易的获取到A的一些信息，如果免于被中间人利用，要保证标识映射到公钥矩阵算法的机密性。这样，即使C获取到了公钥矩阵，它也无法知晓如何从标识映射到公钥矩阵，它也就无法获取到标识的公钥，从而也无法冒充真正的服务器。改进型CPK认证技术的数据交互：基本设想，在客户端和服务器端，分别单向进行密钥交互，即客户端向服务器端发送数据，使用一个对称密钥，服务器向客户端发送数据，使用另外一个对称密钥。系统框架交互流程如下所示：客户端请求密钥交互服务端回应交互情况服务器请求交互密钥客户端回应交互情况使用客户端请求的密钥加密使用服务端的密钥加密1 客户端和服务器端进行连接。2 客户端发送请求密钥交换请求，发送密钥交换数据报文3 服务器回复客户端，交换密钥是否成功，如果成功密钥为A4 服务器发送请求密钥交换请求，发送密钥交换数据报文5 客户端回复服务器，交换密钥是否成功，如果成功密钥为B6 以后，只要是从客户端发送到服务器的数据报文，使用A作为加密密钥7 从服务器发送到客户端的数据报文，使用B作为加密密钥系统风险分析：椭圆曲线密钥交互ECDH算法简介：发起交换一方，随机生成随机数r，rZn，计算r * G = Key，此后Key就作为双方通信的对称密钥。发送方利用接收方的公钥计算：r * IPK，把计算的结果发送给接收方。接收方得到 r * IPK，利用自己的私钥，计算：csk-1*(r*IPK)=r * G = Key，于是双方都得到了同样的值：Key作为对称秘钥加密。中间人攻击分析：中间人利用arp，dns劫持等技术维护客户端和服务器端的连接。中间人冒充服务器：中间人接收到了客户端的密钥交互请求，由于中间人没有真正服务器的私钥，它不能通过计算csk-1*(r*IPK)=r * G = Key，得到对称密钥Key的值。所以它只能选择使用其他方式破解得到服务器的私钥，来计算得到Key，由于破解私钥理论计算上是不行的，所以中间人只能选择把交互数据进行转发，或者丢掉，如果丢掉数据，由于客户端没有收取到服务器的响应，判断此次交互密钥失败。或者中间人C故意回送一个虚假报文，表示此次密钥交互成功。但是在后面，进行客户端向服务端通信的时候，使用对称加密密钥，但是中间人C没有计算出真正的对称密钥，数据报文对于中间人C