求帮助，关于nrf24l01+的防中间人攻击。

Hardison

我只是个高中生准备高二而且我还是文科生，不太懂关于那些加密的（跑题了？）

传输时没有问题的，已经实验了。但是就是怕中间人攻击。

我准备弄个自用的电脑内部控制程序。控制那些风扇，水泵，LED的，返回给服务端的是水温。没什么技术含量。

但是用了24l01后发现这东西只要地址相同就能进行中间人攻击，比如我让24l01发个sleep给电脑端，就关闭LED，但是黑客也可以直接发个Sleep给我的电脑端关了我的LED（水泵那些就更不用说了，关了电脑烧了损失惨重呀）（好像又跑题了）。

现在用了几个加密方法（AES,SipHack)都不行呀。返回来的信息都一样，只要信息一样那么这个加密等于无意义，等于发明文。

希望大家帮帮忙。

Flyback

想要每次都不一样，可用滚动码加密，破解难度会变大

Hardison

Flyback 发表于 2013-8-27 08:22
想要每次都不一样，可用滚动码加密，破解难度会变大

谢谢，我看了下，似乎HCS300是用于汽车上的也被破解了。（又说跑题了）。我已经在国外的论坛上面问了，别人告诉我用chap来认证，我看也可行，产生随机数来加密，然后在明文的控制命令后面加上明文发送随机数再加发送随机数后的密文。接收的收到后用密匙解密密文，与随机数相对应的话就执行命令。用AES128加密来加密随机数。如果随机数与上次相同就丢弃包。这样可行吗？

Flyback

Hardison 发表于 2013-8-27 11:14
谢谢，我看了下，似乎HCS300是用于汽车上的也被破解了。（又说跑题了）。我已经在国外的论坛上面问了，别 ...

以我的理解，滚动码可以适应单向加密控制

如果你打算用双向多次握手的方式，那肯定会增加破解难度

Hardison

Flyback 发表于 2013-8-27 11:28
以我的理解，滚动码可以适应单向加密控制

如果你打算用双向多次握手的方式，那肯定会增加破解难度 ...

我想了下我的方法，也不可行，随机数不可能全部记住，到时RAM会溢出，这样又能破解了。HCS300的话与单片机合作麻烦。而且我的指令也多（通过主控制来控制水泵的PWM,风扇的PWM）.用滚动码不行。如果说要我写个keeloq算法进去也太难了。我现在真不知道怎样验证。脑袋都乱了

xstt

可没有100%破不了的东西，你就算用线连，人家也可以有办法黑你。相对安全就可以。而且你只是自己用。

Hardison

xstt 发表于 2013-8-27 11:45
可没有100%破不了的东西，你就算用线连，人家也可以有办法黑你。相对安全就可以。而且你只是自己用。 ...

谢谢回复，我找到一个方法了，用定时器计时，一个多月都破不了。。。。。唉，真是。没好方法

mhw

你钻牛角尖了……
都说AES128什么的早被破解了……实际上想要那样的牛人动用超级计算机来算计你这玩意，那得多大的面子
现实中却是把芯片打磨一下，在通信协议某个位置对调两个字节，交换一下高低位，加个CRC什么的就可以阻挡99%以上的“攻击”了

mhw

你可以考虑一下在遥控器加一片AT88SA102一类的片子：
1-遥控器发一个正常命令到远端服务器；
2-远端服务器解析命令成功后，先不要执行；产生一个随机数回传给遥控器；
3-遥控器把随机数送入AT88SA102，得到一个指纹，发给远端服务器；
4-远端服务器通过软件算法或配对的芯片，验证指纹是正确的，执行命令。
这种算法是赤裸裸的，目前除非芯片密钥泄露，否则找什么黑客都没用。

Hardison

mhw 发表于 2013-8-27 12:53
你可以考虑一下在遥控器加一片AT88SA102一类的片子：
1-遥控器发一个正常命令到远端服务器；
2-远端服务器 ...

不用太复杂，就是怕中间人攻击而已，程序泄漏没事，你的方法复杂了，我做不到那么高级

Hardison

别人是这样回答的：
edit: The way this works in its simplest form is:
1) the client sends a request to login.
2) server calls timer（you set）, saves that value, and sends that as the challenge to the client.
3) client sends the password and challenge back to the server.
4) both must match to login.

mhw

你仔细对比一下，两个意思是一样的……区别在于我那个多了个硬件加密芯片来保证安全性

javabean

首先是你的方案对安全性要求有多高，如果太高就考虑有线连接吧，这个比较安心
其次你的方案对成本要求是什么，如果你在用51，AVR，那么加密安全性之类的都很难做，有钱可以往高级里升，比如用短信，而且是使用3G网络，使用白名单控制访问列表，安全性明显提升。
最后nRF2401只是一个传输接口，你想要搞安全可以参考蓝牙，跳频，密钥，低功率，高鲁棒性，这个可以有；就怕你研究不透

Hardison

javabean 发表于 2013-8-27 14:31
首先是你的方案对安全性要求有多高，如果太高就考虑有线连接吧，这个比较安心
其次你的方案对成本要求是什 ...

安全性能不用很高，控制命令能用明文传输，而就差验证是否真的是服务端传输的。就是说差个验证方式，希望这个验证方式越安全越好。

javabean

Hardison 发表于 2013-8-27 14:42
安全性能不用很高，控制命令能用明文传输，而就差验证是否真的是服务端传输的。就是说差个验证方式，希望 ...

服务器端和客户端使用相同个密钥，每次使用时间和各自的密钥对数据进行加密，每次只透露时间和相应的结果就可以了。
如果像GSM之类的时间始终同步的系统，那么时间也不用传输了

做到的结果就是每次即使发送相同的数据，无线接口发送的内容也不同，而且服务器客户端间交互从来不发送密钥，只要你的密钥足够长，加密方法采用公开的安全加密，而且客户端做了足够的防御（比如试错多少次拒绝使用一段时间），那么几乎永远不能被破解。
不要用自己写的简单的加密算法，会有漏洞。要使用公开的加密算法哦。

方法是现成的，主要是觉得你如果是客户端用的是单片机没有啥运算能力，其实是说了半天是废话

Hardison

javabean 发表于 2013-8-27 16:11
服务器端和客户端使用相同个密钥，每次使用时间和各自的密钥对数据进行加密，每次只透露时间和相应的结果 ...

我已经打算用随机数和定时器产生的时间来弄明文，再用AES加密，明文和密文一起传送，接收端再校验。大概一个月溢出，我想没人会窃听1个月吧

javabean

明文和密文一起传送?

Hardison

javabean 发表于 2013-8-28 00:04
明文和密文一起传送?

对呀，只发送密文不行呀。用时间加密，时间不同也不行呀。别人发个假包也就乱了，我直接发明文的时间和编码过得时间，接收也就能重编码时间来校验。再加个随机数。。。和chap差不多

Hardison

javabean 发表于 2013-8-28 00:04
明文和密文一起传送?

其实这个不用加密的，数据我可以不管，就是只是验证是否为合法的发送端发送，以确保安全。关于命令明文传送没事

XA144F

循环加密，每加密一次数据后就让密匙循环移动一次。
德国二战时的恩格尼玛密码机就是这样。

javabean

Hardison 发表于 2013-8-28 00:22
其实这个不用加密的，数据我可以不管，就是只是验证是否为合法的发送端发送，以确保安全。关于命令明文传 ...

关键是明文泄露了，就可以绕开你的保护机制来测试密钥了，只看加密后的难度就是不知道你解密出来的数据对不对，你这样把答案告诉人家了，还费这个劲加密校验干嘛

Hardison

javabean 发表于 2013-8-29 10:56
关键是明文泄露了，就可以绕开你的保护机制来测试密钥了，只看加密后的难度就是不知道你解密出来的数据对 ...

他发再多包只要校验不对就丢掉。校验是把接收到的明文在接收端进行加密（用与发送端同样的密匙）再和接收到了密文进行校验。他能仿造明文或密文，但是校验出来是不对的。就直接丢包。

对了，我是新手，有没有办法把Unsigned long转换成byte而无损。。。。（好像不可能。。。。）。

Hardison

javabean 发表于 2013-8-29 10:56
关键是明文泄露了，就可以绕开你的保护机制来测试密钥了，只看加密后的难度就是不知道你解密出来的数据对 ...

我懂你的意思了，那我再把明文的内容加密比较一遍就可以了

javabean

Hardison 发表于 2013-8-28 00:15
对呀，只发送密文不行呀。用时间加密，时间不同也不行呀。别人发个假包也就乱了，我直接发明文的时间和编 ...

GSM是个例子，GSM时间精度都是毫秒级别的，用时间肯定没问题，你的系统可以发送时间或序号，也可以使用校时机制来维持时间精度

Hardison

javabean 发表于 2013-8-29 11:18
GSM是个例子，GSM时间精度都是毫秒级别的，用时间肯定没问题，你的系统可以发送时间或序号，也可以使用校 ...

恩，我的时间也是毫秒级，问题是毫秒级用AES全部加密到时数值一大MCU就可能卡住了。。。所以时间上面我打算用SHA256,随机数用AES（是不是多余了。。。）。