7 ms·

If the OS is actively plotting against you, it's a losing game, but if it's just security-oblivious then there may be some things you can do mitigate. Consider

by zurn 14y ago

If the OS is actively plotting against you, it's a losing game, but if it's just security-oblivious then there may be some things you can do mitigate. Consider for example, an OS with a habit of writing out random parts of your process memory onto disk.

derefr 14y ago
Here's a question I've been pondering: suppose you are a program delivered from an origin (trusted) to a client machine (untrusted.) You start without any credentials, but you have the option of dialing out and asking the origin for a shared secret (e.g. a private key.) Is there any useful way for the origin to require that you, the delivered program, prove that the client machine you're running on can be trusted with the shared secret? If it's possible at all, I'm guessing it involves a "secure boot" with a TPM chip.
- kefka 14y ago
  Why would I want a machine, which I own, trust someone else than the owner? 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).
  - derefr 14y ago
    So you can, for example, participate in a distributed computing project where the results sent in by your machine can be trusted. (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.
    - VLM 14y ago
      "you wouldn't be able to otherwise introspect them" 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.
      - derefr 14y ago
        > Your only hope is playing games with timing. 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. :)
  - deleted 14y ago
    [deleted]
- zurn 14y ago
  Yeah, the "remote attestation" part of the trusted computing stuff was aiming to do that. Didn't really take off. 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.
- VLM 14y ago
  "prove that the client machine you're running on can be trusted" 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)
  - derefr 14y ago
    > That means anyone can run the emulator until it authenticates, then hit pause and start dumping memory to see your "secret" 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"?
  - zurn 14y ago
    > anyone can run the emulator until it authenticates, then hit pause and start dumping memory to see your "secret" 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 http://en.wikipedia.org/wiki/Trusted_Computing
    - VLM 14y ago
      I do apologize for using "secret" in a context where it could apply to either a public key encryption scheme or to the content which is being restricted by the whole scheme. 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.
- gizmo686 14y ago
  I do not think their is a way of doing this for a general purpose computer, but I remember hearing a talk about doing this with small embedded devices (like, say, the microcomputers monitoring the coolant system for your power-plant). The idea is that you send the device enough random bits to completely fill its read/write memory, then require it to send that same stream of bits back. After this, you can re-send it the actual program you want it running.
- chacham15 14y ago
  What's your definition of trust? Trust to execute code faithfully or trust to be who you think it is? In either case, what's required is a base unit that you trust on faith. In the former case the base unit is the signed firmware and the latter case, the root CA.

by zurn 14y ago

derefr 14y ago

Here's a question I've been pondering: suppose you are a program delivered from an origin (trusted) to a client machine (untrusted.) You start without any credentials, but you have the option of dialing out and asking the origin for a shared secret (e.g. a private key.) Is there any useful way for the origin to require that you, the delivered program, prove that the client machine you're running on can be trusted with the shared secret? If it's possible at all, I'm guessing it involves a "secure boot" with a TPM chip.

kefka 14y ago
Why would I want a machine, which I own, trust someone else than the owner? 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).
- derefr 14y ago
  So you can, for example, participate in a distributed computing project where the results sent in by your machine can be trusted. (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.
  - VLM 14y ago
    "you wouldn't be able to otherwise introspect them" 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.
    - derefr 14y ago
      > Your only hope is playing games with timing. 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. :)
- deleted 14y ago
  [deleted]
zurn 14y ago
Yeah, the "remote attestation" part of the trusted computing stuff was aiming to do that. Didn't really take off. 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.
VLM 14y ago
"prove that the client machine you're running on can be trusted" 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)
- derefr 14y ago
  > That means anyone can run the emulator until it authenticates, then hit pause and start dumping memory to see your "secret" 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"?
- zurn 14y ago
  > anyone can run the emulator until it authenticates, then hit pause and start dumping memory to see your "secret" 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 http://en.wikipedia.org/wiki/Trusted_Computing
  - VLM 14y ago
    I do apologize for using "secret" in a context where it could apply to either a public key encryption scheme or to the content which is being restricted by the whole scheme. 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.
gizmo686 14y ago
I do not think their is a way of doing this for a general purpose computer, but I remember hearing a talk about doing this with small embedded devices (like, say, the microcomputers monitoring the coolant system for your power-plant). The idea is that you send the device enough random bits to completely fill its read/write memory, then require it to send that same stream of bits back. After this, you can re-send it the actual program you want it running.
chacham15 14y ago
What's your definition of trust? Trust to execute code faithfully or trust to be who you think it is? In either case, what's required is a base unit that you trust on faith. In the former case the base unit is the signed firmware and the latter case, the root CA.