5 ms·

I have first-hand experience: Around 1999, I wrote a paper about information leakage from blinking LEDs on devices (one DES link encryption box, used by banks,

I have first-hand experience: Around 1999, I wrote a paper about information leakage from blinking LEDs on devices (one DES link encryption box, used by banks, for example, was sending out plaintext on the LEDs). I was working for a defense contractor at the time on a classified project, and so, following procedures, we submitted the paper to NSA for approval to publish. It took a year and a half to approve. [1] Eventually NSA wrote back and said, "No problem! Go ahead and publish." I kind of wonder what they spent all that time doing. [1] Actually, it didn't quite happen that way. Our paper was approved for publication very quickly, in only a few weeks; we submitted it to the USENIX Security Symposium, where it was immediately accepted. Later, NSA called us back, and in a panic, demanded we withdraw the paper from the conference. I had to apologize to the conference committee; it was terribly embarrassing, and the delay in publishing was two years.

sesutton 9y ago
> I kind of wonder what they spent all that time doing. Putting tape over all their LEDs?
nickpsecurity 9y ago
You been alright, Joe? Ever get the new ideas on certification or guards published you were working on when we talked on Schneier's blog? I ended up pivoting into trying to figure out how to secure the hardware. Deep submicron effects, supply chain compromises, and Clive's energy gapping recommendation led me to devise concept of putting TCB or monitors in 0.35 micron or up process node that's visually inspectable. Tear down random sample using others if they're clean. Trusted foundries for packaging. SOI for EMF/fault reductions. Bunch of little CPU's like Clive recommended with CHERI or SAFE extensions working over optical links with filtered/masked power. That's about where past year or two of ideas have led me. Havent built anything: just forwarding concepts to people making guards and such. Curious what others csme up with since most guards have dropped to using Linux on x86 or whatever. Shouldve all been decertified for that shit.
- jloughry 9y ago
  Hi Nick! I'm still working on certification and guards, but in a very early stage company now. Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD. Now I'm working to rid the world of CDS boxes built on PCs running Linux; I know exactly what you mean. It doesn't matter that you're running SE Linux; the vulnerabilities are lower down in the hardware—Meltdown and Spectre and what's coming after Spectre will go right through your VMs and your policy enforcement and your hardened OS. What's needed is a completely different way of solving the cross domain problem; that's what I've got in prototype. I've taught Clive's energy gap notion to my students in university classes. That notion is deeply ingrained in what I'm proposing now. Could I talk with you in more detail about that idea of yours for visually inspectable process node?
  - nickpsecurity 9y ago
    "Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD." Sounds more like engineering or process control than ad hoc. That's a good improvement. Esp if someone is assessing time to market or cost-effectiveness. "that's what I've got in prototype." Good. Hopefully, everyone does it a bit differently, too, for a security through diversity benefit. Too much monoculture going on even in old high-assurance systems that all built on GEMSOS, SNS, STOP, or LOCK. Three of which were really similar in security enforcement, too. "I've taught Clive's energy gap notion to my students in university classes. " He just did another write-up on that with some new channel ideas built-in here: https://www.schneier.com/blog/archives/2018/02/friday_squid_bl_612.html#c6769802 https://www.schneier.com/blog/archives/2018/02/friday_squid_... "Could I talk with you in more detail about that idea of yours for visually inspectable process node?" Sure. Just send an email to the address in my HN profile. It's still good.
    - jloughry 9y ago
      Thanks for the Clive reference. I hadn't seen it.
jey 9y ago
> one DES link encryption box [...] was sending out plaintext on the LEDs What? Care to elaborate? Did they just set the LED brightness based on the current octet being encoded or something? But that seems like it's too high frequency to work.
- jloughry 9y ago
  In the early 1990s when we did this research, it was mostly RS-232 devices; the designers did in fact often connect LEDs directly to the serial TXD and RXD lines, which are relatively high voltage and have plenty of drive capability. Garden variety LEDs are plenty fast enough to reproduce bit transitions in the nanosecond range; we measured intelligible signals in the lab well into megabits per second; on real devices in the field, hundreds of kilobits per second. You're right, the trick wouldn't work so well with modern LVDS levels and speeds, but we examined (at the time) lots of Ethernet NICs with LEDs on them and found no indication there of useful data in the optical region. (It was a different story on the back panel of enterprise Cisco routers....) Ethernet PHY chips invariably, so far as I've seen, implement a pulse stretcher on the LED output pins for exactly the reason you noted. We found no intelligible optical emanations from any of the—admittedly low-cost—Ethernet devices we tested. But since then, two things have happened: USB and HFT. There are definite opportunities for the same thing to happen again. I've seen indications of it in a few USB devices. High Frequency Trading, though, is a whole other can of worms. There, you have FPGAs and ASICs being used to shave nanoseconds off latency, and I wouldn't be a bit surprised to see off-the-shelf gigabit Ethernet PHY chips spurned by fintech specialists designing an extremely specialised piece of hardware to do one job and do it as fast as physics allows. There's a window of opportunity there (sorry!) for rival HFT firms with a telescope and very high speed photodetector to exploit any incautiously wired-up LEDs connected directly to ASIC signals.... Hint: use a photomultiplier; PIN photodiodes are fast but the transimpedance amplifiers they need are s-l-o-w.
- jloughry 9y ago
  The details of the DES encryption vulnerability are all in our paper; it's behind a paywall but you can find it on my web site: J. Loughry and D.A. Umphress. 'Information Leakage from Optical Emanations'. ACM Trans. Info. Sys. Sec. 5(3), pp. 262–289, 2002. Available for free from http://applied-math.org/acm_optical_tempest.pdf http://applied-math.org/acm_optical_tempest.pdf

sesutton 9y ago

> I kind of wonder what they spent all that time doing. Putting tape over all their LEDs?

nickpsecurity 9y ago

You been alright, Joe? Ever get the new ideas on certification or guards published you were working on when we talked on Schneier's blog? I ended up pivoting into trying to figure out how to secure the hardware. Deep submicron effects, supply chain compromises, and Clive's energy gapping recommendation led me to devise concept of putting TCB or monitors in 0.35 micron or up process node that's visually inspectable. Tear down random sample using others if they're clean. Trusted foundries for packaging. SOI for EMF/fault reductions. Bunch of little CPU's like Clive recommended with CHERI or SAFE extensions working over optical links with filtered/masked power. That's about where past year or two of ideas have led me. Havent built anything: just forwarding concepts to people making guards and such. Curious what others csme up with since most guards have dropped to using Linux on x86 or whatever. Shouldve all been decertified for that shit.

jloughry 9y ago
Hi Nick! I'm still working on certification and guards, but in a very early stage company now. Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD. Now I'm working to rid the world of CDS boxes built on PCs running Linux; I know exactly what you mean. It doesn't matter that you're running SE Linux; the vulnerabilities are lower down in the hardware—Meltdown and Spectre and what's coming after Spectre will go right through your VMs and your policy enforcement and your hardened OS. What's needed is a completely different way of solving the cross domain problem; that's what I've got in prototype. I've taught Clive's energy gap notion to my students in university classes. That notion is deeply ingrained in what I'm proposing now. Could I talk with you in more detail about that idea of yours for visually inspectable process node?
- nickpsecurity 9y ago
  "Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD." Sounds more like engineering or process control than ad hoc. That's a good improvement. Esp if someone is assessing time to market or cost-effectiveness. "that's what I've got in prototype." Good. Hopefully, everyone does it a bit differently, too, for a security through diversity benefit. Too much monoculture going on even in old high-assurance systems that all built on GEMSOS, SNS, STOP, or LOCK. Three of which were really similar in security enforcement, too. "I've taught Clive's energy gap notion to my students in university classes. " He just did another write-up on that with some new channel ideas built-in here: https://www.schneier.com/blog/archives/2018/02/friday_squid_bl_612.html#c6769802 https://www.schneier.com/blog/archives/2018/02/friday_squid_... "Could I talk with you in more detail about that idea of yours for visually inspectable process node?" Sure. Just send an email to the address in my HN profile. It's still good.
  - jloughry 9y ago
    Thanks for the Clive reference. I hadn't seen it.

jey 9y ago

> one DES link encryption box [...] was sending out plaintext on the LEDs What? Care to elaborate? Did they just set the LED brightness based on the current octet being encoded or something? But that seems like it's too high frequency to work.

jloughry 9y ago
In the early 1990s when we did this research, it was mostly RS-232 devices; the designers did in fact often connect LEDs directly to the serial TXD and RXD lines, which are relatively high voltage and have plenty of drive capability. Garden variety LEDs are plenty fast enough to reproduce bit transitions in the nanosecond range; we measured intelligible signals in the lab well into megabits per second; on real devices in the field, hundreds of kilobits per second. You're right, the trick wouldn't work so well with modern LVDS levels and speeds, but we examined (at the time) lots of Ethernet NICs with LEDs on them and found no indication there of useful data in the optical region. (It was a different story on the back panel of enterprise Cisco routers....) Ethernet PHY chips invariably, so far as I've seen, implement a pulse stretcher on the LED output pins for exactly the reason you noted. We found no intelligible optical emanations from any of the—admittedly low-cost—Ethernet devices we tested. But since then, two things have happened: USB and HFT. There are definite opportunities for the same thing to happen again. I've seen indications of it in a few USB devices. High Frequency Trading, though, is a whole other can of worms. There, you have FPGAs and ASICs being used to shave nanoseconds off latency, and I wouldn't be a bit surprised to see off-the-shelf gigabit Ethernet PHY chips spurned by fintech specialists designing an extremely specialised piece of hardware to do one job and do it as fast as physics allows. There's a window of opportunity there (sorry!) for rival HFT firms with a telescope and very high speed photodetector to exploit any incautiously wired-up LEDs connected directly to ASIC signals.... Hint: use a photomultiplier; PIN photodiodes are fast but the transimpedance amplifiers they need are s-l-o-w.
jloughry 9y ago
The details of the DES encryption vulnerability are all in our paper; it's behind a paywall but you can find it on my web site: J. Loughry and D.A. Umphress. 'Information Leakage from Optical Emanations'. ACM Trans. Info. Sys. Sec. 5(3), pp. 262–289, 2002. Available for free from http://applied-math.org/acm_optical_tempest.pdf http://applied-math.org/acm_optical_tempest.pdf