Are passwords stored in memory safe?
security.stackexchange.com
security.stackexchange.com
Here's some interesting reading: http://en.wikipedia.org/wiki/TRESOR
And no, I do not trust the TPM in its current iteration. We mere owners are prevented from knowing its private key. Nor can we generate and store away a private key (or buy a known private keyed chip).
(An online game that calculates physics client-side is a special case of a distributed computing project ;)
It doesn't require you to give up ownership over your entire computer, mind you. If your own OS ran in a hypervisor that was in one TPM "domain" (you have the key to this domain), but then applications could request to be run directly on the hypervisor with a separate TPM domain (and thus keep keys your own OS wouldn't ever be able to touch), that'd be good enough to allow for any secure distributed computation you might want to do. At any time, you'd still be able to wipe out those domains (and thus kill the apps running in them)--but you wouldn't be able to otherwise introspect them.
Basically, it's like the duality of "OS firmware" and "baseband firmware" on phones--except it would all be being handled on the same real CPU.
The standard way of handling distributed clients is with trust calculations. A simeon trust calculation is to duplicate a packet of work multiple times and/or process questionable ones yourself. If they match, you can bump up the trust calculation on that client.
Public key crypto is all fine and good. It's great for executables so you know who they came from (hmm, trust again..).
So why can't I have the private key to a tpm I buy or have integrated in my motherboard?
Can't implement it until you define its behavior. If you define its behavior you can emulate it (which, outside this discussion, is really useful). If you can emulate it, you can single step it, breakpoint it, dump any state of the system including memory, reboot it into "alternative" firmware...
Your only hope is playing games with timing. So here's a key, and its only valid for one TCP RTT. Well if they want to operate over satellite they must allow nearly a second, so move your cracking machine next door and emulate a long TCP path and you've got nearly a second now. On the other hand if instead of runnin over the internet you merely wanted to prove bluetooth distances or google wallet NFC distances, suddenly you've gone from something I can literally do at home easily to a major lab project.
Another thing that works is "prove you're the fastest supercomputer in the world by solving this CFD simulation in less than X seconds". Emulating that would take a computer much faster than the supposedly fastest computer. So this is pretty useful for authenticating the TOP500 supercomputer list, but worthless for consumer goods.
This is inane. My question was about mathematically provable secure computation, not kludges that any old advanced alien civilization could bypass by sticking your agent-computer in a universe simulator. :)
Let's ignore the computers. You are a spy dispatched from Goodlandia to Evildonia. You want to meet with your contact and exchange signing keys. You can send a signal at any time to Goodlandia that will tell them to cut off all contact with you, because you believe you have been compromised. (A certificate revocation, basically.)
Your contact, thus, expects one of three types of messages from you:
1. a request for a signing key with an attached authentication proof;
2. a message, signed with a key, stating you have been compromised and to ignore all further messages sent using that key;
3. or a message, signed with a non-revoked key, containing useful communication.
Now, is there any possible kind of "authentication proof" that you could design, such that, from the proof, it can be derived that:
1. you have not yet been compromised;
2. you will know when you have been compromised;
3. and that, in the case of compromise, you will be allowed to send a revocation message before any non-trusted messages are sent?
You can assume anything you like about the laws of Evildonia to facilitate this--like that it is, say, single-threaded and cooperatively multitasking--but only if those restrictions can also carry over to the land of Neoevildonia, a version of Evildonia running inside an emulator. :)
None the less, if you want to exclude computers, the human equivalent of "stick it in an emulator" is the old philosopher's "brains in a vat" problem. That's well traveled ground no there is no proof you're not in a vat.
There is no way to prove you have not been compromised because there is no way to prove no theoretical advancement will ever occur in the field in the future. (or not just advancement but NSA declassification, etc) So you're limited to one snapshot in time, at the very least.
You're asking for something that's been trivially broken innumerable times outside the math layer.
Its hard to say if you're asking for steganography (which isn't really "math") or an actual math proof or you just want a wikipedia pointer to the kerberos protocol which is easily breakable but if you add enough constraints it might eventually fit your requirements.
None of those; I know the current state of the art in cryptography/authentication, and that it doesn't quite cover what I'm asking for. I'm basically just waiting for you to say that the specific kind of designed proof I asked for is impossible even in theory, so I can go and be sad that my vision for a distributed equivalent to SecondLife[1] will never happen.
My own notion would be that the Goodlandian agent would simply request that his contact come and look at the machine itself, outward-in, and verify to him that he's running on a real, trusted piece of hardware with no layers of emulation, at which point the contact gives him an initial seed for a private key he will use to communicate with from then on. The agent stores that verification on his TPM as a shifting nonce (think garage-door openers), so that whenever the TPM is shut down, it immediately becomes invalid as far as the contact is concerned--and must be revalidated by the contact again coming and looking at the physical machine. All we have to guarantee after that is that any method of introspecting the TPM on a piece of currently-trusted-hardware fries the keys. Which is, I think, a property TPMs already generally have?
Besides being plain-ol' impractical [though not wholly so; it'd be fine for, say, inspecting and then safe-booting military hardware before each field-deployment], I'm sure there's also some theoretical problem even here that renders it all moot. I'm not a security expert. :)
---
[1] More details on that: picture a virtual world (technically, a MOO) to which any untrusted party can write and hot-deploy code to run inside an "AI agent"--a self-contained virtual-world object that gets a budget of CPU cycles to do whatever it likes, but runs within its own security sandbox. Also picture that people who are in the same "room" as each AI agent are running an instance of that agent on their own computers, and their combined simulation of the agent is the only "life" the agent gets; there is no "server-side canonical version" of the agent's calculations, because there are no servers (think Etherpad-style collaboration, or Bitcoin-style block-chain consensus.)
Now, problematically, AI agents could sometimes be things like API clients for out-of-virtual-world banks. Now how should they go about repudiating their own requests?
Majority rule not consensus. Given a mere majority rule protocol, I think your virtual world idea could work.
But you could also be running, instead, on an emulator on Harry's computer--and Harry wants Alice's credit card info. So now Harry reaches in and steals the key BigBank gave you, then deploys a copy of you back into the mesh, hardcoded to use that session key. Alice then unwittingly uses Harry's version of you--and Harry MITMs her exchange.
In ordinary Internet transactions, this is avoided because Alice just keeps an encryption key (a pinned cert) for BigBank, and speaks to them directly. If you, as an agent, are passed a request for BigBank, it's one that's already been asymmetrically encrypted for BigBank's eyes only. And that works... if the bank is running outside of the mesh.
But if the bank is itself a distributed service provided by the mesh? Not so much. (I'm not sure how much of a limitation that is in practice, though, other than "sadly, we cannot run the entire internet inside the mesh.")
Well your remote server prover, is going to need a bunch of unit tests and some kind of load testing "system" for scalability testing, so rather than piling dozens of physical clients on your desk you may as well make a client emulator that can run in a virtual image... Oh whoops. That means anyone can run the emulator until it authenticates, then hit pause and start dumping memory to see your "secret"
Basically if you can define "it" to run on a turing complete machine, "it" can be run on any other turing complete machine. You may have some interesting games to play with timing and speed but that's usually not too hard to work around if the emulator is more powerful than whats being emulated, or if the protocol is sloppily implemented (which is the norm)
I would presume that "semantically-correct" emulation of a TPM-based authentication protocol would require that the VM software runs in ring 0 and uses the host's TPM for guest storage. Anything else would be emulating "something that acts like TPM, but offers none of the guarantees of TPM."
I'm just not sure how an emulated TPM would be able to figure out that it's not fulfilling its semantic function.
That seems to be the key, here: is there anything a TPM chip could investigate before saying "yep, I'm not running emulated--I can see the Real Hardware I was created for right there--so I'll let programs trust me"?
TPMs are implemented as tamper resistant hardware modules. As long as you can't read out the keys, you can't have the the emulator authenticate.
It's all explained here http://en.wikipedia.org/wiki/Trusted_Computing
Another issue is "tamper resistant" is just a big wrapper around a security thru obscurity design. Its not "mathematically provable" its just here's a secret number we hope doesn't show up on wikileaks.
Nowadays people have dreamed up applications for it in server hosting, where you can talk to the DRM in your rented server and get some assurance your software running there hasn't been comproimsed.
If one want to leave the OS altogether, One could also use a external physical security device, through it too need to be done in a correct way. Some hardware encryption acceleration devices might have an option to store keys only locally and never give it away to the host, but I doubt this is true for all.
See http://en.wikipedia.org/wiki/Homomorphic_encryption for more.
But there are best practices for passwords, and those reduce the risks; and most attacks need privileges and access to the machine, which again reduces the risk.
If you're worried about stormtroopers kicking the door down and squirting liquid nitrogen on the RAM you probably have enough money to have very strong perimeter defences.
I wouldn't know, though.
Paper on that: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf
Much safer (but slower) is to hook directly into the bus and communicate with the ram itself. I guess its a trade off between speed and security, which mean it depend on the case specifics.
Everyone should read the mitigation steps and caveats as appropriate.
If you have physical access to an unlocked windows machine, i'd reach for mimikatz. Instant plaintext.
See for example:
0wned by an iPod - hacking by Firewire http://md.hudora.de/presentations/#firewire-pacsec
More papers are linked in the wikipedia page: http://en.wikipedia.org/wiki/DMA_attack
http://msdn.microsoft.com/en-us/library/ms995355.aspx
I've been using it for years, and while nothing is infallible, any sensitive plain text in my apps isn't there for more than it takes to encrypt and then destroy.
I can't comment on Linux or OSX but would be surprised if the OS didn't offer a similar API tied to the principal to protect in-memory data.
> Reading comments here and on stackexchange I'm surprised
> that no mention is made of the Data Protection API (DPAPI)
> on Windows, which is designed specifically for this purpose.
1) if it can be decrypted by the API, then it can be cracked by any process given enough time and resources.
2) further to point #1, the Data Protection API was reversed engineered in 2010.
3) security is only as strong as your weakest link, and that API doesn't address the "weakest link" of running malware locally. eg it's much easier to keylog passwords to begin with than to scan the RAM.
I'm inclined to agree with those comments. While that API is a nice idea, I think it's a little ineffective in practice.
Both of those seem easy enough to fix, which I imagine Microsoft has done (the exploit was discovered 3 years ago). I'm going to do a little more research when I have time.
Lastly, and importantly, this attack is an offline attack. I wasn't able to find anything that compromises in-memory data. Granted, nothing other than 2FA will protect anyone (or DPAPI) against key loggers, but that's true for all OSs.
If local malware is the strength of the argument against DPAPI then I might as well go so far as to say that the most secure system is no system.
> Both of those seem easy enough to fix, which I imagine Microsoft has
> done (the exploit was discovered 3 years ago). I'm going to do a little
> more research when I have time.
However, regardless of whether it has or hasn't, said patches only increase the CPU time it takes to crack the passwords, it doesn't make the passwords impossible to crack. And, as I'd already said, there's weaker links that can be exploited anyway.
> Lastly, and importantly, this attack is an offline attack.
> Granted, nothing other than 2FA will protect anyone (or DPAPI) against key
> loggers, but that's true for all OSs.
> If local malware is the strength of the argument against DPAPI then
> I might as well go so far as to say that the most secure system is no system.
For the average user, social engineering will always remain the most exploited vector of attack, and for ultra sensitive servers, all we can do is lock them down as best as we can based on the latest fixes and proof-of-concepts. But a sufficiently determined attacker will usually find a way in if there's a sufficiently high enough incentive. Our job (or at least mine), is to make it sufficiently hard that attackers lose interesting trying. But if they've gained root access (in order to run any of the aforementioned attacks), then it's already game over - regardless of whether they manage to decrypt your RAM or not. Which is why I think the aforementioned API is akin to the emperors new clothes (ie all hype, no practical security)
http://docs.oracle.com/javase/tutorial/uiswing/components/pa...
This will leave the "hello" in ram (subject to GC):
String x = "hello"
x = null;
char[] x = new char[]{'h','e','l','l','o'};
x[0] = '0'; x[1] = '0'; ...
char[] x = new char[]{'h','e','l','l','o'};
x = null;Even then, the password must reside in memory at some point in order to compute the hash of your password [using bycrypt or whatever scheme], which is necessary for both generating the hash the first time AND generating the hash for authentication attempts. This is the issue described in the given link.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Pas...
Storing a hash doesn't help because the remote site won't accept it. And if it did then the hash is essentially the password and you've violated the goal.
Fravia said of dongles that they were often great, with nice libraries, but when software vendors implemented them they would use stupid methods.
(http://home.scarlet.be/detten/tuts/dongle_zeezee.htm)
> Don't panic when you read all info about dongle security. They ARE secure. OK. You can't crack them unless they're done by complete idiots. OK. But you want to crack the application, NOT the dongle. When you read about RSA encryption, one-way functions and see in the API some interesting Question/Answer hashing functions, remember that it's only API. No one uses it. Only simple functions like Check/Serial Number/Read and sometimes Write are used.
Combine that with per-application virtualization and various forms of user authentication (other than passwords), and public key cryptography, and you could probably start to build substantially more secure services. Same stuff on clients and servers.
ARM's TrustZones are actually more interesting than TPMs on x86; you can essentially start the general purpose CPU as a trusted device and then partition off less-trusted pieces. If you're going to have a single processor, vs. a specialized security processor, this is probably how to do it, not the x86 + TPM + TXT way.
Probably all meaningless until there's a framework as simple as Ruby on Rails was vs. everything else in 2005, or php, which makes doing things securely the easy default.
A more appropriate question would have been: 'How safe is it to store passwords in memory?'
And even that is not 100% foolproof (the OS can detect it in between these two steps).
Gaining you exactly nothing.
It's using DAPI which derives the encryption key from the user password.
Not that it helps in any way at all.
Just don't store it character for character the same as the password when used to authenticate the user.
You could have the even characters in one array and the odd characters in another and this would make it a bit safer.
I'm not sure every app needs to be this paranoid but I offer it as an idea that can be easily implemented for those that do.
You've just described encryption here, whilst saying that its not encryption.
The principle is right though. A simple obfuscation will deter most attacks.
Bottom line: there is no such thing like security against local attacks on almost any kind of commodity hardware (including TPMs, excluding devices explicitly designed to be reasonably secure like gaming consoles). When you need that you also need proper tamper-proof hardware.
edit: finish the sentence