The best path to strong security has always been hardware isolation, right? So now that we have mass-market microcomputers, why bother with VMs? What do you think of Tinfoil Chat[0]? The notebook form factor could contain several microcomputers, with optical isolation, or even outright air gapping. But closed-source hardware and firmware is still problematic :(
Closed source hardware is indeed a problem: If the HW of TxM is pre-compromised, the device/malware running on it might spit out what it thinks is the key via serial or alternative covert channel.
If you start developing on top of TFC, please create a Github fork at some point and submit pull requests to any typos / issues you might find.
Not really. I started thinking that but not really sure. There's a number of models. The thing the preventative ones all have in common is they impose control on the flow of information in such as way as to prevent attacks. Separation, like address spaces, is a recurring concept and technique but not the only one. So, I use the term "information flow control" albeit it might be used differently in academia. The other model, covered by diversity and obfuscation, is to create a disconnect between what attacker envisions and what they can accomplish to create probabilistic security. The first is great against "known knowns" and "known unknowns:" specific attacks or non-specific worries in known risk areas. The second is great against straight unknowns, esp tricks nation states devise. Combining the two is most powerful and hence my recommendation. Many models of each, which further muddles things for attackers.
Far as Tinfoil Chat, I've recommended it heartily as a project to use and improve. Markus Ottela took what he learned from prior work and our comments at Schneier's blog (esp on data diodes & physical separation) to create a unique, solid design. He's been posting on the blog for feedback for months, we've suggested many risk mitigations (eg polyciphers, continuous transmission), and he's integrated about every one into his system. Most just ignore such things or make excuses: Markus is 1 in a 1,000 in (a) applying what's proven and (b) not letting problems become legacy "features."
So, yeah, I recommend it. Once my personal situation stabilizes, I plan to reimplement it with a tiny TCB on appropriate devices. I'm probably going to do a portable implementation of Send for microcontroller-style systems. Receive will be a Linux box hardened with virtualization or obfuscation security methods. Genode if it's up to it by then. The transport will be a more hardened, cheap box with just that functionality. I'm going to use CHERIBSD, if possible, just to experiment with it. Might replace the raw, serial links with MCU's or FPGA's for higher-speed, one-way I/O. Optical is highly likely (good guess). Eventually, I'm going to put it in an appliance with several, cheap boards so it's all integrated.
On my extensive backlog for now. But, yes, it's one of the best and practically has no TCB. Great design. Can be reused for email, audio, video, and maybe filesharing. Will be my interim framework until my next high-assurance system is ready.
It's gotten backlogged for me too. I started obsessing about potential EM coupling across optoisolators. But to test, I need a Faraday cage and gear. ...
Anyway, I'll check out the discussion on Schneier's blog.
It's kind of spread out all over the place lol. Would be difficult to even integrate. For Tinfoil, it's best to just grab the code of the Poly variety and start using/improving it. Far as the 100+ other topics, I can give you a list of links to my designs and essays there if you want to dig through for something worth building on. All I ask is credit as Nick P for whatever part my work contributes.
Comments
The best path to strong security has always been hardware isolation, right? So now that we have mass-market microcomputers, why bother with VMs? What do you think of Tinfoil Chat[0]? The notebook form factor could contain several microcomputers, with optical isolation, or even outright air gapping. But closed-source hardware and firmware is still problematic :(
[0] https://github.com/maqp/tfc-otp
Closed source hardware is indeed a problem: If the HW of TxM is pre-compromised, the device/malware running on it might spit out what it thinks is the key via serial or alternative covert channel.
If you start developing on top of TFC, please create a Github fork at some point and submit pull requests to any typos / issues you might find.
Not really. I started thinking that but not really sure. There's a number of models. The thing the preventative ones all have in common is they impose control on the flow of information in such as way as to prevent attacks. Separation, like address spaces, is a recurring concept and technique but not the only one. So, I use the term "information flow control" albeit it might be used differently in academia. The other model, covered by diversity and obfuscation, is to create a disconnect between what attacker envisions and what they can accomplish to create probabilistic security. The first is great against "known knowns" and "known unknowns:" specific attacks or non-specific worries in known risk areas. The second is great against straight unknowns, esp tricks nation states devise. Combining the two is most powerful and hence my recommendation. Many models of each, which further muddles things for attackers.
Far as Tinfoil Chat, I've recommended it heartily as a project to use and improve. Markus Ottela took what he learned from prior work and our comments at Schneier's blog (esp on data diodes & physical separation) to create a unique, solid design. He's been posting on the blog for feedback for months, we've suggested many risk mitigations (eg polyciphers, continuous transmission), and he's integrated about every one into his system. Most just ignore such things or make excuses: Markus is 1 in a 1,000 in (a) applying what's proven and (b) not letting problems become legacy "features."
So, yeah, I recommend it. Once my personal situation stabilizes, I plan to reimplement it with a tiny TCB on appropriate devices. I'm probably going to do a portable implementation of Send for microcontroller-style systems. Receive will be a Linux box hardened with virtualization or obfuscation security methods. Genode if it's up to it by then. The transport will be a more hardened, cheap box with just that functionality. I'm going to use CHERIBSD, if possible, just to experiment with it. Might replace the raw, serial links with MCU's or FPGA's for higher-speed, one-way I/O. Optical is highly likely (good guess). Eventually, I'm going to put it in an appliance with several, cheap boards so it's all integrated.
On my extensive backlog for now. But, yes, it's one of the best and practically has no TCB. Great design. Can be reused for email, audio, video, and maybe filesharing. Will be my interim framework until my next high-assurance system is ready.
Thanks!
It's gotten backlogged for me too. I started obsessing about potential EM coupling across optoisolators. But to test, I need a Faraday cage and gear. ...
Anyway, I'll check out the discussion on Schneier's blog.
It's kind of spread out all over the place lol. Would be difficult to even integrate. For Tinfoil, it's best to just grab the code of the Poly variety and start using/improving it. Far as the 100+ other topics, I can give you a list of links to my designs and essays there if you want to dig through for something worth building on. All I ask is credit as Nick P for whatever part my work contributes.
Thanks for the warning :)
I'd appreciate whatever links you can share. And I would be glad to credit you.
Forgot to tell you that I emailed it to your RiseUp address.