You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Data in the process of network transmission, will pass through many intermediate nodes, packets may be monitored, tampered, dropped by firewall protocol blacklist, etc. In order to solve these problems, BDT has also made considerations and implementation in security, it supports full data encryption, and header hash obfuscation, making the upper layers completely invisible, eliminating protocol data characteristics, with my understanding of the code, I will discuss the implementation of BDT with you, and welcome correction and your own ideas.
1. BDT Tunnel
First of all, when two devices communicate with each other using BDT, both establish Tunnel before data transmission, and there are two ways of transmission in Tunnel: plaintext and encryption. Since ciphertext is much stronger in security, BDT Tunnel will encrypt the data of upper layer (Datagram, Stream, etc.) by default.
Taking the data exchange between LN and RN as an example, the encrypted Tunnel communication process is as follows:
(1) LN>RN: EXCHANGE_KEY with SYN_TUNNEL
(2) RN>LN: EXCHANGE_KEY_OK with ACK_TUNNEL
(3) LN>RN: ACKACK_TUNNEL with DATA
(4) RN>LN: DATA
(5) … …
(1) and (2) are AES_KEY and MIX_KEY exchange processes, and merge SYN_TUNNEL and ACK_TUNNEL packets for establishing Tunnel (please refer to the detailed protocol packet codec document), The data in (1) at the beginning of communication is encrypted by LN with RN's public key, and then decoded by RN with private key after receiving it, and after exchanging AES_KEY, subsequent data transmission use it for AES encryption and decryption.
2. Tunnel package header format
Tunnel's underlying transport is currently based on UDP and TCP over IP.
(1) For TCP:
+----------+-----------------------+
| Len 2B | AES encryption Data |
+----------+-----------------------+
(2) For UDP:
+--------------+-----------------------+
| MixHash 8B | AES encryption Data |
+--------------+-----------------------+
So the whole process of data interaction in Tunnel is based on asymmetric encryption algorithm and AES encryption algorithm for encryption and decryption, and the protocol data in the upper layers of Tunnel are not visible, so the protocol headers in the upper layers cannot be identified.
3. MixHash
3.1 What is MixHash?
In UDP mode, after LN and RN exchange AES_KEY, the packet sent to the other side has a fixed 8B-length header, and the data of this header is Hash(MIX_KEY). After the other side receives the packet, it looks up its own cached KeyHash, so as to know who sent this packet and what AES_KEY is, and then decodes it with the AES_KEY.
However, in the subsequent communication process, this 8B packet header data will become a kind of Tunnel's data characteristic if it remains unchanged. In order to eliminate this characteristic, the KeyHash is generated by adding a time variable, at this time MixHash=Hash(MIX_KEY+Time+d), "Time" is the local time, and "d" is a MixTimeRange, default is [-15min, +15min].
3.2 Mixing Process
(1) LN, RN calibrate the local system time
(2) After EXCHANGE_KEY, LN, RN have negotiated AES_KEY, MIX_KEY
(3) MixHash=Hash(MIX_KEY+Time+d)，d default is [-15,15]
(4) LN, RN keep updating MixHash every 1min
(5) LN, RN look up the corresponding AES_KEY in the cache for encryption and decryption by MixHash
After MixHash, the first 8B of each Tunnel packet changes over time and the protocol header no longer has specific characteristics.
4. Packet capture and analysis
Two machines are deployed locally, one running SN server and one running SN client as LN. After initializing the protocol stack, LN calls stack.sn_client().ping().wait_online() to send ping packets to SN and ping keepalive once every 3s, both LN & SN have synchronized their time, use tcpdump to capture packets on LN.
4.1 Running environment:
LN: ubuntu 18.04 sn-client, IP 192.168.10.100 Gateway 192.168.10.1
LN-Gateway: eth0 IP 192.168.10.1, eth1 IP 10.10.10.100
SN: ubuntu 18.04 sn-miner, IP 10.10.10.3
As the above shows, after negotiating AES_KEY and MIX_KEY, the first Mixhash header is 0dbc766908da54be, which changes to 6a3eb7cd612fe9e4 after 1 minute. In the case of AES encryption, every time a ping request is sent, the Tunnel data has no characteristics and cannot be decrypted.
The Mixhash of the first package after restarting the program is 9d55f13a780987e3, which is different from the Mixhash 9ede0bba42541beec of first run, so the package characteristics of SN EXCHANGE_KEY is also not obvious and cannot be seen from the data only.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Data in the process of network transmission, will pass through many intermediate nodes, packets may be monitored, tampered, dropped by firewall protocol blacklist, etc. In order to solve these problems, BDT has also made considerations and implementation in security, it supports full data encryption, and header hash obfuscation, making the upper layers completely invisible, eliminating protocol data characteristics, with my understanding of the code, I will discuss the implementation of BDT with you, and welcome correction and your own ideas.
1. BDT Tunnel
First of all, when two devices communicate with each other using BDT, both establish Tunnel before data transmission, and there are two ways of transmission in Tunnel: plaintext and encryption. Since ciphertext is much stronger in security, BDT Tunnel will encrypt the data of upper layer (Datagram, Stream, etc.) by default.
Taking the data exchange between LN and RN as an example, the encrypted Tunnel communication process is as follows:
(1) and (2) are AES_KEY and MIX_KEY exchange processes, and merge SYN_TUNNEL and ACK_TUNNEL packets for establishing Tunnel (please refer to the detailed protocol packet codec document), The data in (1) at the beginning of communication is encrypted by LN with RN's public key, and then decoded by RN with private key after receiving it, and after exchanging AES_KEY, subsequent data transmission use it for AES encryption and decryption.
2. Tunnel package header format
Tunnel's underlying transport is currently based on UDP and TCP over IP.
(1) For TCP:
(2) For UDP:
So the whole process of data interaction in Tunnel is based on asymmetric encryption algorithm and AES encryption algorithm for encryption and decryption, and the protocol data in the upper layers of Tunnel are not visible, so the protocol headers in the upper layers cannot be identified.
3. MixHash
3.1 What is MixHash?
In UDP mode, after LN and RN exchange AES_KEY, the packet sent to the other side has a fixed 8B-length header, and the data of this header is Hash(MIX_KEY). After the other side receives the packet, it looks up its own cached KeyHash, so as to know who sent this packet and what AES_KEY is, and then decodes it with the AES_KEY.
However, in the subsequent communication process, this 8B packet header data will become a kind of Tunnel's data characteristic if it remains unchanged. In order to eliminate this characteristic, the KeyHash is generated by adding a time variable, at this time MixHash=Hash(MIX_KEY+Time+d), "Time" is the local time, and "d" is a MixTimeRange, default is [-15min, +15min].
3.2 Mixing Process
(1) LN, RN calibrate the local system time
(2) After EXCHANGE_KEY, LN, RN have negotiated AES_KEY, MIX_KEY
(3) MixHash=Hash(MIX_KEY+Time+d)，d default is [-15,15]
(4) LN, RN keep updating MixHash every 1min
(5) LN, RN look up the corresponding AES_KEY in the cache for encryption and decryption by MixHash
After MixHash, the first 8B of each Tunnel packet changes over time and the protocol header no longer has specific characteristics.
4. Packet capture and analysis
Two machines are deployed locally, one running SN server and one running SN client as LN. After initializing the protocol stack, LN calls stack.sn_client().ping().wait_online() to send ping packets to SN and ping keepalive once every 3s, both LN & SN have synchronized their time, use tcpdump to capture packets on LN.
4.1 Running environment:
4.2 First run of LN, data interaction flow:
(1) LN>SN EXCHANGE_KEY
UDP_DATA: 9ede0bba42541beec47d65761eea82…b45dfeb3e
(2) SN>LN EXCHANGE_KEY_OK
UDP_DATA: 0dbc766908da54be91bb0a96d11678…371fc0614
(3) LN> SN PING_REQUEST
UDP_DATA: 0dbc766908da54be3f5d14ddffd5e1…e73d29957df1
(4) SN>LN PING_RESPONSE
UDP_DATA: 0dbc766908da54bed333e3a75913…bf3cb954a7ccba
(5) LN>SN: SN_PING_REQUEST
UDP_DATA: 0dbc766908da54be7d5a1b847af8…2fdd06238944cc
(6) SN>LN: PING_RESPONSE
UDP_DATA: 0dbc766908da54bebf6ed2b176b2…012b54ac55f050
(7) LN>SN: SN_PING_REQUEST
UDP_DATA: 0dbc766908da54bea0462993b77…518712412130a
1 minute later..
(i) LN>SN: SN_PING_REQUEST
UDP_DATA: 6a3eb7cd612fe9e4ffe7ee5c448a7…e8a47f178ab892
(i+1) SN>LN PING_RESPONSE
UDP_DATA: 6a3eb7cd612fe9e4a91dfaefe74a…e5dcef1c8d1c053738
As the above shows, after negotiating AES_KEY and MIX_KEY, the first Mixhash header is 0dbc766908da54be, which changes to 6a3eb7cd612fe9e4 after 1 minute. In the case of AES encryption, every time a ping request is sent, the Tunnel data has no characteristics and cannot be decrypted.
4.3 LN 2nd run:
(1) LN>SN EXCHANGE_KEY
UDP_DATA: 9d55f13a780987e330f0486853921c232c23a…c68d5900817b02
(2) SN>LN EXCHANGE_KEY_OK
UDP_DATA: 591fbf6d4f8ddda4c03bcd01d64f508b039bf0…6cf6b5199b0e75d
(3) LN>SN PING_REQUEST
UDP_DATA: 591fbf6d4f8ddda4434c97dc7b7ad146c8a65…5b97f3c62afa248e
(4) SN>LN PING_RESPONSE
UDP_DATA: 591fbf6d4f8ddda4f7f6ff18db1e6b1a6460c9…f69d8bab62e516b3
The Mixhash of the first package after restarting the program is 9d55f13a780987e3, which is different from the Mixhash 9ede0bba42541beec of first run, so the package characteristics of SN EXCHANGE_KEY is also not obvious and cannot be seen from the data only.
Beta Was this translation helpful? Give feedback.
All reactions