Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
On Fri, Oct 25, 2013 at 08:12:00AM -0400, John Kelsey wrote:
This gets back to the threat model discussion. If your attacker is watching you from the outside as you generate your key, then interacting with stuff over the local net won't help you much. (You may get a bit or two of entropy from the attacker not being able to know exactly which clock-tick you were on when the interrupt was serviced, but not much.). If he's not watching you then, you can rule out a whole category of attackers.
Yes, absolutely. For example, if you assume that the attacker has network taps at Fort Meade and in a phone closets of companies like AT&T, they are very likely not going to be able to watch your LAN traffic. OTOH, if they have physical access to your LAN such that they can drop an agent close to your computer that can monitor all of the packets hitting your computer, we have to ask how are they doing this? If they can someone break into your local ethernet switch remotely, then you might be in a world of hurt (although usually switches generally don't have enough of general purpose CPU that this is likely). If you posit a "black bag" job where they physically break into your house, and replace your ethernet switch, then they could presumably place a keyboard bug on your keyboard, or otherwise physically tamper with your computer, install audio/video surveillance equipment in an HVAC duct, etc. --- and then you're either doing something really black hatish, or I have a tin foil hat to sell to you, or possibly both. :-) My challenge as someone who is designing things like a general purpose /dev/random is that it's challenging to determine which assumptions about the threat environment might make sense in a large set of hypothetical scenarios, and which do not. I can imagine scenarios where the adversary is on a public network --- say, at a University dorm network --- who might be able to watch interpacket network arrival times, but who probably can't make a lot of assumptions about HDD completion drive times --- and the user might want to generate a securely long-term public key for their ssh host key or for GPG. I'm less willing to accept as a valid threat model one where the adversary has near-total control over _all_ entropy sources, *and* can divine the state of the prng, but has no other access to the system so they can't break root in other ways, *and* where if you can't prove that you can make the prng secure again, it's somehow horrible and your rng is not robust (and that the authors of said paper should deserve lots of citations so they can get a suitably high impact score on their way to achieving tenure :-). But maybe there are scenarios where such a threat environment is actually realistic. I'm certainly willing to hear someone try to give me an example of such a threat environment; it would probably be quite educational. - Ted _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
For example, if you assume that the attacker has network taps at Fort Meade and in a phone closets of companies like AT&T, they are very likely not going to be able to watch your LAN traffic. OTOH, if they have physical access to your LAN such that they can drop an agent close to your computer that can monitor all of the packets hitting your computer, we have to ask how are they doing this? If they can someone break into your local ethernet switch remotely, then you might be in a world of hurt (although usually switches generally don't have enough of general purpose CPU that this is likely).
What else is on your LAN besides a network switch? Do you have a printer with an Ethernet jack? Or a DSL modem? Or a cable modem? Or a low-end commercial NAS box? All of these typically run an embedded system using some old version of Linux, and never get their firmware updated to close zero-day security holes. If one of them can be taken over, and can convince your network switch to send them all the packets (perhaps by ARP flooding or ARP spoofing), then that embedded system can wiretap any LAN transaction it likes. Many DSL modems contain a small switch, which if it's the only switch in a small home or office network, would make all packets among local nodes accessible to malware running in that DSL modem. Many cheap Ethernet switches are 'intelligent' meaning that they have an embedded processor that offers a Web configuration interface. Such devices are fertile malware targets. Automated global-scale attacks against such embedded systems are certainly feasible. Could the injected code be sufficiently subtle to detect and store or report entropy events like packet timing, without becoming sufficiently obvious that the malware's presence is detected on the network? John PS: On the "big iron" rather than "small network" end of things, don't forget virtual machines, in which a compromised VM hypervisor has full access to all the packets (and to many other aspects of the machines running under it). _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 10/28/2013 04:20 AM, John Gilmore wrote:
Could the injected code be sufficiently subtle to detect and store or report entropy events like packet timing, without becoming sufficiently obvious that the malware's presence is detected on the network?
No. Knowing "packet timing" isn't good enough. It is the interrupt timing that matters, and even that isn't good enough, at least not in the case of a fast CPU with a GHz+ system clock: you have to know the value of a fast counter at the moment that it is sampled as part of servicing the interrupt. The clock the attacker needs to know doesn't even exist outside the chip in question. An attacker needs to infer very precise phase angles here, or a bit or more of entropy will slip through on that interrupt. And you expect to measure this via malware running on a cheap printer plugged into feet of ethernet cable plus an ethernet switch plus more cabling between it and the computer that gets the interrupt? The malware might make an estimation of interrupt timing, but it can't get down to the last LSB of that clock at the moment when the CPU gets around to reading it. We are talking not just an off-chip measurement of a signal that doesn't exist off-chip, we are talking about doing it from outside the box, when the box isn't trying to cooperate. Making timing measurments precisely is hard to do in the best possible and most carefully engineered circumstances. -kb _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Many DSL modems contain a small switch, which if it's the only switch in a small home or office network, would make all packets among local nodes accessible to malware running in that DSL modem.
And most DSL modems are provided by your giant telco DSL provider -- such as AT&T -- which we already know has a long history of covertly sucking up to NSA. Besides their longstanding cooperation on domestic and foreign fiber taps, they also produced the first-and-only Clipper Chip subverted "telephone security device" for making voice calls that "nobody but NSA" could listen to. How hard would it be, really, for them to subvert all their DSL modems to wiretap your LAN? And how would you know if they had done so? It's so convenient that all AT&T DSL modems have a high bandwidth upstream connection to AT&T's central office switches. And even better that consumers have no idea what packets are going up and down over that DSL signalling, because they have no equipment for monitoring raw 2-wire DSL lines (the way they could fairly easily detect inappropriate packets traveling on an Ethernet, with a little free software and a little replugging of Ethernet equipment). Your DSL modem could be doing its main job (carrying your external Internet traffic) using whatever fraction of the available bandwith that requires in each millisecond, and using any spare capacity on the DSL wire to mirror a select fraction, or all, of your local LAN traffic up to the central office switch. The switch would nominally discard this 'filler traffic' -- but AT&T would be able to copy it to NSA upon request, either by individual targeting of particular customers, or wholesale. In the better subverted DSL modems, the filler/tap traffic would be fully encrypted between the modem and the switch, so that even if you got professional equipment for monitoring the DSL wire back to the central office, all you would see is 'random' filler packets all the time. Suppose AT&T and NSA really had no interest in doing this to you -- unlikely, I know -- but the Chinese manufacturers of DSL modems did have such an interest? The threat model is very similar, except the Chinese would have to subvert the AT&T central office switches covertly, without AT&T's willing cooperation, to extract your LAN traffic from them. You can guard against this threat by only plugging one Ethernet jack into your DSL modem, and having that lead directly to a Linux or BSD gateway box that is under your own control. That way, the DSL modem has no physical access to the rest of your LAN, and you can monitor the upstream Ethernet to make sure that the only packets going to the DSL modem are those that you intended to go upstream. John _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 10/28/13 11:56 -0800, John Gilmore wrote:
Many DSL modems contain a small switch, which if it's the only switch in a small home or office network, would make all packets among local nodes accessible to malware running in that DSL modem.
And most DSL modems are provided by your giant telco DSL provider -- such as AT&T -- which we already know has a long history of covertly sucking up to NSA. Besides their longstanding cooperation on domestic and foreign fiber taps, they also produced the first-and-only Clipper Chip subverted "telephone security device" for making voice calls that "nobody but NSA" could listen to. How hard would it be, really, for them to subvert all their DSL modems to wiretap your LAN?
Many DSL modems that I've evaluated are Linux based, and are subject to GPL requests. I've gotten my hands on a build tarball from a couple of different vendors which include a cross compiler, GPL source (for the portion of the code which is not proprietary), compiled Linux kernel (which contains proprietary drivers), and one or more proprietary binaries which, from what I can tell, are primarily used to maintain the local configuration. The result is a firmware which voids your warranty when uploaded, but works. Vendors often use the same firmware base, which is typically provided by the chipset vendor (e.g. Broadcom). There were several modems I could break root shell on with a shell escape sequence from the telnet/ssh menu. None of this may be available if you're using an xBell branded modem (or whoever your telco is). However, if you know a few details about your xDSL connection (vpi/vci etc.), you could likely purchase your own modem, using your own generated firmware. Granted, there are still proprietary software components involved.
And how would you know if they had done so? It's so convenient that all AT&T DSL modems have a high bandwidth upstream connection to AT&T's central office switches. And even better that consumers have no idea what packets are going up and down over that DSL signalling, because they have no equipment for monitoring raw 2-wire DSL lines (the way they could fairly easily detect inappropriate packets traveling on an Ethernet, with a little free software and a little replugging of Ethernet equipment).
Generally xDSL connections do not use a high amount of upstream bandwidth, unless you've got ADSL2+ Annex M or VDSL2 going on. Your modem, if you have access, will report the up and down sync rate, which is consistent with the rate reported by the DSLAM in my experience. To attempt to transmit data outside of the DSL layer, using frequencies outside of the sync rate is difficult, would involve cooperation from a lot of different vendors, and would be a poor used of resources. Compromise of your data would more likely be handled in software, at layer 3. Placing your modem in bridged mode, with an open source router behind is a very good idea (as you mentioned). -- Dan White BTC Broadband _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Mon, Oct 28, 2013, at 02:56 PM, John Gilmore wrote:
You can guard against this threat by only plugging one Ethernet jack into your DSL modem, and having that lead directly to a Linux or BSD gateway box that is under your own control. That way, the DSL modem has no physical access to the rest of your LAN, and you can monitor the upstream Ethernet to make sure that the only packets going to the DSL modem are those that you intended to go upstream.
Which, by the way, is impossible if you have U-Verse and have either television or phone service. -- Shawn K. Quinn skquinn@rushpost.com
participants (5)
-
Dan White -
John Gilmore -
Kent Borg -
Shawn K. Quinn -
Theodore Ts'o