3 ms·

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced wit

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)

pdkl95 6y ago
> The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

pdkl95 6y ago

> The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html