Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deniability and Duress

mit.edu

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Deniability and Duress

#91

Post by RcouF1uZ4gsC »

loup-vaillant wrote: post #25
sspiff wrote: post #16

Earlier quoted context omitted.

Except that travellers may be (and sometimes are being) asked for login credentials to online accounts.

I'm sure we can think of a "double lock" feature, where you allow a friend to lock you out of your account. There's even an easy local solution: encrypt your data with a friend's public key (sealed box in libsodium parlance). It may be seized and intercepted, but you can't possibly decrypt it. That's probably the kind of scheme Snowden used when he arranged his inability to decrypt his NSA data even if captured and t…

The really bad people, are probably at that point going torture you just to make an example of you to discourage others from doing the same.

Re: Deniability and Duress

#92

Post by bzbarsky »

CJefferson wrote: post #61
mynegation wrote: post #33

Earlier quoted context omitted.

I immediately thought the same thing upon reading. One thing that comes to mind is: automatically triggered data destruction. If laptop or the phone detects non-owner access attempts and destroys data on its own, is it destruction of evidence? Owner did not do it, and it was there just to protect from the real bad guys: corporate spies, identity thieves.

The law often uses intention. Could you convince a jury of your peers you didn't do this just to hide your stuff from law enforcement?

Yes, if it was the default OS behavior. Which is the argument the article makes.

Re: Deniability and Duress

#93

Post by mulmen »

michaelt wrote: post #55

The first two paragraphs of the article are about a journalist covering war crimes exiting a country and being searched. Fifth amendment distinctions between passwords and fingerprints aren't a solution to the problems in Egypt, China and Turkey as those countries aren't subject to US law. In that situation, from one perspective a duress code that wiped the phone might seem useful - it would establish that there's no…

Could a cooperative effort to create a plausible body of work help in these situations? A journalist could keep a plausible number of canned stories on their machine and when the duress code is triggered everyone stops using them and more are written to take their place.

What level of quality in the writing is needed? Can some kind of news aggregating algorithm generate plausible stories? Some kind of propaganda bot that writes stories that are favorable to the regime for the purpose of creating a plausible cover?

Do I need to go get more coffee and watch fewer spy movies?

Re: Deniability and Duress

#94

Post by kilotaras »

SilasX wrote: post #86
ianferrel wrote: post #81

Earlier quoted context omitted.

Truecrypt is a (now discontinued) encryption program that allowed you to nest encrypted containers within one another in a way that if you provided Password1, it would open Container1, and if you provided Password2, it would open Container2. Since the Container's full size was allocated at creation, and the size of the contents cannot be determined without the key, this gave plausible deniability. You could keep your…

But isn't it a non-trivial problem to generate plausible fake data?

Truecrypt didn't generate fake date, you (the user) did. E.g. put porn on "show to thugs" partition and "Death star plans" on "true" encrypted partition.

Re: Deniability and Duress

#95

Post by mspecter »

tomp wrote: post #30

> Scanning a pinky (or some other fingerprint / combination of fingerprints) might cause the phone to factory reset, or unlock and trigger deletion a specified portion of user data. IANAL, but AFAIK there is a strict line between not providing incriminating evidence (legal, protected under 5th Amendment) and destroying evidence (criminal).

The theory is that the cops would be the ones selecting the finger. This would be no different from LE trying to crack a password, and the system permanently locking them out. However, I am also Not A Lawyer.

Re: Deniability and Duress

#96

Post by _hnwo »

Not sure if this was mentioned already but Kali Linux includes a patch for cryptsetup that essentially does this - provide a certain passphrase and it nukes the keyslots, effectively making the data irrecoverable.

https://www.kali.org/tutorials/emergency-self-destruction-lu... and tutorial for use at https://www.kali.org/tutorials/nuke-kali-linux-luks/

and the patch on github;

https://github.com/offensive-security/cryptsetup-nuke-keys

Re: Deniability and Duress

#98

Post by smellf »

SilasX wrote: post #86
ianferrel wrote: post #81

Earlier quoted context omitted.

Truecrypt is a (now discontinued) encryption program that allowed you to nest encrypted containers within one another in a way that if you provided Password1, it would open Container1, and if you provided Password2, it would open Container2. Since the Container's full size was allocated at creation, and the size of the contents cannot be determined without the key, this gave plausible deniability. You could keep your…

But isn't it a non-trivial problem to generate plausible fake data?

    echo "Truecrypt test" > /mnt/plausible_deniability_volume/README && history -d $(history | tail -n1 | cut -d' ' -f1)

Re: Deniability and Duress

#99

Post by DennisP »

stinkytaco wrote: post #82
miend wrote: post #76

Earlier quoted context omitted.

I use this combo whenever possible, though the number of services yet supporting FIDO/U2F is still a bit disappointing. It's been incredibly convenient to be able to use my bitcoin hardware wallets to double as U2F keys wherever I need them. Given that any device I would use an OTP or text 2FA solution with already requires time to unlock, it's far less convenient on top of being more exploitable.

Are you using the ledger as a wallet? Doesn't plugging the device into an untrusted PC worry you at all? Leaving all that aside, the biggest issue for me an u2f is the mobile problem I have a yubikey neo, but u2f does not work over nfc, so I'm still stuck creating application passwords for things.

The Ledger is designed to plug into an untrusted PC, that's the whole point. It's running secure hardware and never reveals the private key. It also has a display that tells you how much you're sending and to what address, so you're protected even if you have spyware that attempts to spoof those parameters.

According to Yubikey, "All YubiKey NEO devices manufactured as of February 10, 2015 supported the current FIDO U2F specification for NFC."

https://www.yubico.com/products/yubikey-hardware/yubikey-neo...

Maybe you have an older device? Or, if you have an iPhone, it's Apple that's the problem, since it restricts NFC to Apple's own payment system. With Android, NFC is available to any app.

Re: Deniability and Duress

#100

Post by monochromatic »

rl3 wrote: post #27

Any solution that has to maintain plausible deniability must be resistant to automated forensic exploitation suites commonly sold to law enforcement. The pre-boot authentication phase is far harder to attack than an operating system that has already booted, so the only solution I can see is a typical hidden volume setup with two independent operating systems. The capability needs to be baked into both iOS and Android…

> It has zero national security value

I'm against it too, but of course it has more than zero national security value.

Post reply on HN