5 ms·

In light of this, here's a fun paper/idea (+implementation) to consider: "Neuroscience Meets Cryptography: Designing Crypto Primitives Secure Against Rubber Ho

by wfn 13y ago

In light of this, here's a fun paper/idea (+implementation) to consider: "Neuroscience Meets Cryptography: Designing Crypto Primitives Secure Against Rubber Hose Attacks" https://crypto.stanford.edu/~dabo/pubs/abstracts/rubberhose.html https://crypto.stanford.edu/~dabo/pubs/abstracts/rubberhose.... (summary; full paper (PDF): http://bojinov.org/professional/usenixsec2012-rubberhose.pdf http://bojinov.org/professional/usenixsec2012-rubberhose.pdf) Abstract: "Cryptographic systems often rely on the secrecy of cryptographic keys given to users. Many schemes, however, cannot resist coercion attacks where the user is forcibly asked by an attacker to reveal the key. These attacks, known as rubber hose cryptanalysis, are often the easiest way to defeat cryptography. We present a defense against coercion attacks using the concept of implicit learning from cognitive psychology. Implicit learning refers to learning of patterns without any conscious knowledge of the learned pattern. We use a carefully crafted computer game to plant a secret password in the participant's brain without the participant having any conscious knowledge of the trained password. While the planted secret can be used for authentication, the participant cannot be coerced into revealing it since he or she has no conscious knowledge of it. We performed a number of user studies using Amazon's Mechanical Turk to verify that participants can successfully re-authenticate over time and that they are unable to reconstruct or even recognize short fragments of the planted secret." The scheme/system is bound to be imperfect; but it is a nice angle of approach, so to speak, and hopefully we'll have more stuff of this kind in the near future. edit / P.S.: from the paper / intro section: Readers who want to play with the system can check out the training game at brainauth.com/testdrive

jwr 13y ago
It is interesting, but has little to do with the original article, as the police will kindly ask the accused to authenticate, instead of asking for the key.
- wfn 13y ago
  You are right, when you look at it like that, my comment was a bit of a hijack. The threat model in question assumes that the attackers know that the person in question has a way to auth / is part of an encrypted / limited access system, which is a very sensible assumption (and is included in the police/accused scenario in any case.) I was probably thinking something along the lines of, [this proposed system] + a way for the user to discretely convey to the auth/security system the info that they are being coerced, and the system authenticating them to a bogus user account / set of sensitive data. But this would be cumbersome and very difficult to implement given the design in question, probably. It would have probably been more relevant to mention encryption systems with plausible deniability - e.g. TrueCrypt's hidden volumes [1] and Rubberhose FS [2]. [1]: http://www.truecrypt.org/hiddenvolume http://www.truecrypt.org/hiddenvolume [2]: http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29 http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
anologwintermut 13y ago
This does not do cryptography at all. It authenticates that you know a "password" that the system already has to have to do the auth process. As a result anyone how has your system either has your private keys or can derive them trivially.
- wfn 13y ago
  If by 'system' you mean the one the user is authenticating to, then yes, afaik. For one to have data encryption, it'd have to be coupled together with a data encryption solution. If 'system' (in your last sentence) means 'user system' ('has' -> keylogger etc), it's not that simple afaik. There's no way for any eavesdropper (between client and server) to know (from the auth game data the server sends) which parts of the data/exchange signify the password. I think they partly addressed possible password/data correlation attacks over multiple logins -> sets of data, but not sure if in this paper, it's been a while. It's not that trivial as far as I take it.
  - anologwintermut 13y ago
    I meant the former. As far as I recall, the latter may have been possible. Their security model required someone physically authenticate it was a human logging into the system. This was to prevent someone from attaching a computer and using it to fake the responses to the challenges. I assume they were in fact worried it would do so by "learning" the real answer, but I can't recall.
anonymous 13y ago
Sounds like Murakami's "Hard-Boiled Wonderland and The End of The World". Even so, you can give the password by playing the game, which is why I would prefer to keep it in some form even I can't read and which is easy to be accidentally destroyed by the police when they seize your stuff.

by wfn 13y ago

jwr 13y ago

It is interesting, but has little to do with the original article, as the police will kindly ask the accused to authenticate, instead of asking for the key.

wfn 13y ago
You are right, when you look at it like that, my comment was a bit of a hijack. The threat model in question assumes that the attackers know that the person in question has a way to auth / is part of an encrypted / limited access system, which is a very sensible assumption (and is included in the police/accused scenario in any case.) I was probably thinking something along the lines of, [this proposed system] + a way for the user to discretely convey to the auth/security system the info that they are being coerced, and the system authenticating them to a bogus user account / set of sensitive data. But this would be cumbersome and very difficult to implement given the design in question, probably. It would have probably been more relevant to mention encryption systems with plausible deniability - e.g. TrueCrypt's hidden volumes [1] and Rubberhose FS [2]. [1]: http://www.truecrypt.org/hiddenvolume http://www.truecrypt.org/hiddenvolume [2]: http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29 http://en.wikipedia.org/wiki/Rubberhose_%28file_system%29

anologwintermut 13y ago

This does not do cryptography at all. It authenticates that you know a "password" that the system already has to have to do the auth process. As a result anyone how has your system either has your private keys or can derive them trivially.

wfn 13y ago
If by 'system' you mean the one the user is authenticating to, then yes, afaik. For one to have data encryption, it'd have to be coupled together with a data encryption solution. If 'system' (in your last sentence) means 'user system' ('has' -> keylogger etc), it's not that simple afaik. There's no way for any eavesdropper (between client and server) to know (from the auth game data the server sends) which parts of the data/exchange signify the password. I think they partly addressed possible password/data correlation attacks over multiple logins -> sets of data, but not sure if in this paper, it's been a while. It's not that trivial as far as I take it.
- anologwintermut 13y ago
  I meant the former. As far as I recall, the latter may have been possible. Their security model required someone physically authenticate it was a human logging into the system. This was to prevent someone from attaching a computer and using it to fake the responses to the challenges. I assume they were in fact worried it would do so by "learning" the real answer, but I can't recall.

anonymous 13y ago

Sounds like Murakami's "Hard-Boiled Wonderland and The End of The World". Even so, you can give the password by playing the game, which is why I would prefer to keep it in some form even I can't read and which is easy to be accidentally destroyed by the police when they seize your stuff.