久久久久久久999_99精品久久精品一区二区爱城_成人欧美一区二区三区在线播放_国产精品日本一区二区不卡视频_国产午夜视频_欧美精品在线观看免费

標題: 關于MCU間通信防監(jiān)聽問題 [打印本頁]

作者: zyftank 時間: 2024-1-4 18:31
標題: 關于MCU間通信防監(jiān)聽問題
我現(xiàn)在準備做個設備認證的東西，在每個機械設備上裝個帶有身份驗證的PCB板，然后主控板向該PCB板發(fā)送指令，返回加密的認證信息，主控芯片進行解密，看身份驗證信息是否一致。

但是，這里有個問題，如果通過串口或者485發(fā)送這些信息，很容易被人監(jiān)聽被截取，別人也就可以寫個程序對驗證的密文進行偽造。

大神們，有沒有方法可以做到，防止串口或485通信防監(jiān)聽的辦法？

作者: szb314 時間: 2024-1-5 08:52
沒有絕對的加密，只有更多的麻煩，要么你試試量子糾纏？

作者: 18680365301 時間: 2024-1-5 09:05
坐等大神思路

作者: Hephaestus 時間: 2024-1-5 09:08
加隨機數(shù)就行了，這樣每次你主控板發(fā)送的密文都不一樣，就算被人監(jiān)聽，PCB板也只知道幾億億次隨機密文中的一種回復，如何仿造？？？

作者: devcang 時間: 2024-1-5 10:21

光是加密不夠的，做到同1條指令、都是不同的數(shù)據(jù)，基本可以了。

作者: glinfei 時間: 2024-1-5 10:30
有密碼機的，就是比較貴，通常都是軟件上想辦法。簡單的就做個哈希，也很難破解的。順便還可以不斷改改串口的波特率。

作者: 18680365301 時間: 2024-1-5 10:34
主機發(fā):
TEA加密(消息ID + Buf[0] + Buf[1] + Buf[2] + Buf[3] + 隨機數(shù) + 隨機數(shù) + 隨機數(shù) + 隨機數(shù)+ 校驗)

從機回發(fā):
TEA加密(主機消息ID + Buf[0] + Buf[1] + Buf[2] + Buf[3] + 隨機數(shù) + 隨機數(shù) + 隨機數(shù) + 隨機數(shù)+ 校驗)

這樣通信怎樣??有沒大神知道一番

作者: 18680365301 時間: 2024-1-5 10:44

主機發(fā):
以9600波特率發(fā)送
TEA加密(消息ID + 隨機波特率 + Buf[1] + Buf[2] + Buf[3] + 隨機數(shù) + 隨機數(shù) + 隨機數(shù) + 隨機數(shù)+ 校驗)
波特率設置為隨機波特率等待從機回發(fā)(某段時間內(nèi)無法接收到從機回發(fā)數(shù)據(jù),再次返回9600波特率重新發(fā)送)
從機回發(fā):
設置波特率為主機隨機波特率
TEA加密(主機消息ID + Buf[0] + Buf[1] + Buf[2] + Buf[3] + 隨機數(shù) + 隨機數(shù) + 隨機數(shù) + 隨機數(shù)+ 校驗)
設置波特率為9600等待主機重新更新波特率

這樣又怎樣??

這樣通信怎樣??有沒大神知道一番

作者: Hephaestus 時間: 2024-1-5 10:52

18680365301 發(fā)表于 2024-1-5 10:34
主機發(fā):
TEA加密(消息ID + Buf[0] + Buf[1] + Buf[2] + Buf[3] + 隨機數(shù) + 隨機數(shù) + 隨機數(shù) + 隨機數(shù)+ ...

如果每個數(shù)據(jù)幀都只有8 bytes那么這么做就對了，如果是很長的連續(xù)數(shù)據(jù)沒必要用這么多隨機數(shù)，8個字節(jié)插入1個就行。

作者: yzw846562238 時間: 2024-1-5 16:09

Hephaestus 發(fā)表于 2024-1-5 10:52
如果每個數(shù)據(jù)幀都只有8 bytes那么這么做就對了，如果是很長的連續(xù)數(shù)據(jù)沒必要用這么多隨機數(shù)，8個字節(jié)插入 ...

可以生成個uint32_t類型隨機數(shù)RNG[0]、RNG[1]、RNG[2]、RNG[3]，假如你的消息有5字節(jié)，[ID]、[buf1]、[buf2]、[buf3]、[buf4]、[crc0]、[crc1]、[crc2]、[crc3]。可以把[ID]^RNG[0]、[buf1]^RNG[1]、[buf2]^RNG[2]、[buf3]^RNG[3]、[buf4]^RNG[0]，然后在[buf4]后面添加RNG[0]、RNG[1]、RNG[2]、RNG[3]，計算crc32填入[crc0]、[crc1]、[crc2]、[crc3]，收到報文后逆向異或，這樣兩個相同功能的報文，可以做到?jīng)]一個字節(jié)是一樣的，讓人摸不著頭腦

作者: Hephaestus 時間: 2024-1-5 16:34

yzw846562238 發(fā)表于 2024-1-5 16:09
可以生成個uint32_t類型隨機數(shù)RNG[0]、RNG[1]、RNG[2]、RNG[3]，假如你的消息有5字節(jié)，、、、、、[crc0] ...

你搜下TEA、XTEA、XXTEA、salsa20、ChaCha20、Poly1305……

作者: XLinliY.Zhang 時間: 2024-1-5 16:57
滾動碼 + AES加密 + 加鹽就可以了

作者: zyftank 時間: 2024-1-6 16:22
感謝各位老鐵的熱心解答。

作者: zyftank 時間: 2024-1-6 16:26
感謝各位老鐵的熱心解答。其實我的問題主要是防別人截獲我的通信密文，但是這個是沒辦法阻止的。簽名認證有一套自己的算法HMAC，這些算法肯定比一般的算法強，防監(jiān)聽辦法就是加個時間戳驗證，即使別人截獲了你的密文，發(fā)過來一樣通不過驗證，因為你的密文是過時的。

作者: Hephaestus 時間: 2024-1-7 08:52
HMAC基礎算法還是DES、AES什么的，既然你有這么大的單片機資源能算規(guī)模這么大的算法，我就不說什么了。

作者: isyido 時間: 2024-1-7 12:11
用較長位數(shù)的偽隨機數(shù)生成器，將你的數(shù)據(jù)作為初始數(shù)據(jù)送進去，運行特定次后得到的數(shù)據(jù)作為通信數(shù)據(jù)，這樣，亂碼通信，解密會有點障礙。

作者: isyido 時間: 2024-1-7 12:13

Hephaestus 發(fā)表于 2024-1-7 08:52
HMAC基礎算法還是DES、AES什么的，既然你有這么大的單片機資源能算規(guī)模這么大的算法，我就不說什么了。

9494，晃了一眼HMac，感覺很高端的樣子。哈哈哈

作者: zyftank 時間: 2024-1-7 17:21

Hephaestus 發(fā)表于 2024-1-7 08:52
HMAC基礎算法還是DES、AES什么的，既然你有這么大的單片機資源能算規(guī)模這么大的算法，我就不說什么了。

不稿HMAC了，只是用時間戳加DES加密，再添加幾個隨機數(shù)以及把數(shù)組位置變換一下。

作者: zyftank 時間: 2024-1-7 17:37

yzw846562238 發(fā)表于 2024-1-5 16:09
可以生成個uint32_t類型隨機數(shù)RNG[0]、RNG[1]、RNG[2]、RNG[3]，假如你的消息有5字節(jié)，、、、、、[crc0] ...

我現(xiàn)在的問題不是要解密，問題是防止別人偽造你發(fā)過的報文，如果發(fā)個你前面發(fā)過一模一樣的報文，能不能騙過上位機？

作者: Hephaestus 時間: 2024-1-8 00:43

zyftank 發(fā)表于 2024-1-7 17:37
我現(xiàn)在的問題不是要解密，問題是防止別人偽造你發(fā)過的報文，如果發(fā)個你前面發(fā)過一模一樣的報文，能不能騙 ...

隨機數(shù)是上位機發(fā)的，下位機發(fā)前面一模一樣的報文，怎么可能騙過上位機？

原來我們說了半天，你根本就不看。

作者: zyftank 時間: 2024-1-8 08:50

Hephaestus 發(fā)表于 2024-1-8 00:43
隨機數(shù)是上位機發(fā)的，下位機發(fā)前面一模一樣的報文，怎么可能騙過上位機？

原來我們說了半天，你根本就 ...

你這種也可以試出來，就是把上位機發(fā)的隨機數(shù)改成固定，從下位機返回數(shù)據(jù)破解，破解有點難度。

作者: TTQ001 時間: 2024-1-8 08:50
可以監(jiān)控RS232或RS485通信的串口連接，一旦連接未通過驗證，通信將被關閉。

作者: yuxuesuixing 時間: 2024-1-8 09:40
硬件方面：接口錯亂，不使用標準的串口和485接口，畢竟是內(nèi)聯(lián)電路板，完全可以自定義接口，比如單總線或者多跟信號線，沒點技術還真分析不出來。協(xié)議方面：協(xié)議可以搞個比如變頻異步，一般人就分析不出來了，簡單一點也可以搞個4b-8b 將一個字節(jié)數(shù)據(jù)拆分到兩個字節(jié)中，兩字節(jié)中總共有8b的隨機碼。加密方面：網(wǎng)上加密方法有很多現(xiàn)成的，弄個AES128，一般的32位處理器沒啥壓力。

作者: Hephaestus 時間: 2024-1-9 23:10

zyftank 發(fā)表于 2024-1-8 08:50
你這種也可以試出來，就是把上位機發(fā)的隨機數(shù)改成固定，從下位機返回數(shù)據(jù)破解，破解有點難度。

上位機都已經(jīng)破了，你還加密個蛋啊！

作者: hellojacky123 時間: 2024-1-10 18:03
為了防止串口或485通信被監(jiān)聽，可以考慮以下幾種方法：

硬件加密：使用帶有加密功能的串口或485通信模塊。這些模塊可以在數(shù)據(jù)傳輸時進行硬件加密，以保護數(shù)據(jù)的安全性。
自定義協(xié)議：設計一個自定義的通信協(xié)議，該協(xié)議在傳輸數(shù)據(jù)時對數(shù)據(jù)進行加密，并采用特殊的格式或指令來標識身份驗證信息。這樣，即使數(shù)據(jù)被截取，也很難被偽造。
加密算法：采用強大的加密算法，如AES、RSA等，對數(shù)據(jù)進行加密。這樣可以在一定程度上防止數(shù)據(jù)被破解。
定期更換密鑰：為了防止密鑰被破解，可以定期更換密鑰，使得截取的數(shù)據(jù)在一段時間內(nèi)無效。
物理隔離：通過物理方式隔離串口或485通信線路，如使用光纜或特殊的線路保護裝置，以防止數(shù)據(jù)被截取。
軟件加密：在軟件層面進行加密處理，如對傳輸?shù)臄?shù)據(jù)進行加密后再傳輸，并在接收端進行解密。這樣可以增加數(shù)據(jù)的安全性。
校驗和：在數(shù)據(jù)傳輸時添加校驗和，以檢測數(shù)據(jù)是否被篡改。如果校驗和不匹配，則可以重新傳輸數(shù)據(jù)或進行身份驗證。

作者: zyftank 時間: 2024-1-11 15:02

Hephaestus 發(fā)表于 2024-1-9 23:10
上位機都已經(jīng)破了，你還加密個蛋啊！

呵呵，既然你接三根線就能收到下位機的通信數(shù)據(jù)，你把RX和TX對調一下，不就能收到上位機發(fā)送的數(shù)據(jù)？

作者: Hephaestus 時間: 2024-1-11 17:15

zyftank 發(fā)表于 2024-1-11 15:02
呵呵，既然你接三根線就能收到下位機的通信數(shù)據(jù)，你把RX和TX對調一下，不就能收到上位機發(fā)送的數(shù)據(jù)？

能收到又怎么樣？？？

作者: zyftank 時間: 2024-1-12 10:19

Hephaestus 發(fā)表于 2024-1-11 17:15
能收到又怎么樣？？？

串口通信，信道是根本沒有保密可言，都是在外裸奔。

歡迎光臨 (http://www.zg4o1577.cn/bbs/)