[Crypto-chi] Hardware tokens

Sat Feb 21 10:00:08 CST 2015

hello everyone
this goes back to wot Freddie said late last year. SIM cards aren't secure.
Those naughty boys at the NSA and GCHA are up to their dastardly deeds again. Read all about it!
thoughts?-Joe
https://firstlook.org/theintercept/2015/02/19/great-sim-heist/?t=dXNlcmlkPTQ3ODYxNDMwLGVtYWlsaWQ9OTUyOQ==

> Date: Sat, 27 Dec 2014 14:50:00 -0600
> From: freddymartinez9 at gmail.com
> To: cryptoparty-chi at groups.sshchicago.org; mchap88 at gmail.com
> Subject: Re: [Crypto-chi] Hardware tokens
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> I just picked up a FIDO U2F Security Key. I'll report my findings at
> the next cryptoparty/CCC. Having to remember passwords is WYFU.
> 
> > This is known as key escrow, and it's a bad thing if you don't 
> > trust your escrow service (and why should you?) Lockheed was bitten
> > by
> 
> Actually your sentence could be better written as: "This is known as
> key escrow and its a bad thing.
> 
> CCC will be mid/late-January
> 
> On 12/23/2014 05:10 PM, Jesse Young wrote:
> > I remember the SecurID breach, but only looked up the details
> > recently. I doesn't look like there was a problem with the token
> > itself, rather RSA (the company) kept a copy of all the secrets
> > resident on the tokens. This is known as key escrow, and it's a bad
> > thing if you don't trust your escrow service (and why should you?)
> > Lockheed was bitten by it. Really the only parties that should have
> > had the secret were Lockheed and their employees (with the
> > employee's copy locked up in the token.)
> > 
> > Shared secret tokens (like the SecurID) are also less of an
> > interest to me, because the secret, by definition, needs to be
> > available to the service you're authenticating against. It does
> > seem to be more popular on the web these days (see Google
> > Authenticator / OATH). I have it set up for my email.
> > 
> > I think the hardware tokens can be made secure precluding poor 
> > implementations. In fact some cryptoprocessors have anti-tampering 
> > features that are purported to defend against highly sophisticated 
> > and expensive attacks.
> > 
> > FWIW, everything I know about the SecurID breach came from this 
> > Slashdot discussion: 
> > http://yro.slashdot.org/story/11/06/07/129217/rsa-admits-securid-tokens-have-been-compromised
> >
> >  Tell me more about the CCC, is there a separate mailing list /
> > resources from the cryptoparty's?
> > 
> > Jesse
> > 
> > On Tue, 23 Dec 2014 14:08:15 -0600 Matt Chapman <mchap88 at gmail.com>
> > wrote:
> > 
> >> On-topic: With hardware tokens, never forget: 
> >> http://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise
> >>
> >>
> >> 
> Off-topic-ish:
> >> How's CCC going? I'd love to go to one, but haven't heard much
> >> about it since the last crypto party.
> >> 
> >> Matt
> >> 
> >> On Tue, Dec 23, 2014 at 1:58 PM, Freddy Martinez 
> >> <freddymartinez9 at gmail.com> wrote:
> >> 
> >>> Off-topic: lol. GSM SIM cards are not secure.
> >>> 
> >>> On-topic
> >>> 
> >>> I love this topic. I have been looking at hardware tokens out
> >>> of curiosity for work and have a few ideas as well. I'd love to
> >>> see something like this Jesse.  My concern is that this would
> >>> be out of scope for cryptoparty but we could do something like
> >>> this at CCC. The goal for CCC was to do more advanced level
> >>> talks and create a place for working on projects like this.
> >>> 
> >>> Freddy
> >>> 
> >>> On Tue, Dec 23, 2014 at 1:42 PM, Jesse Young <jlyo at jlyo.org>
> >>> wrote:
> >>>> Hey all,
> >>>> 
> >>>> I've taken an interest in hardware based security tokens on
> >>>> Linux lately. Let's just say it's a big painful mess of
> >>>> components that don't quite work together [1]. I've come up
> >>>> with a set of requirements for my personal setup that I think
> >>>> are achievable, although it has and will take quite a bit of
> >>>> work. I've surveyed the ecosystem, and came up with a set of
> >>>> requirements that I think are achievable.
> >>>> 
> >>>> My requirements are: 1. All secrets must be stored or wrapped
> >>>> in hardware 2. All secret keys must be unextractable 3. New
> >>>> key generation must be done in hardware 4. Existing keys must
> >>>> be able to be imported into hardware
> >>>> 
> >>>> As far as application integration goes, here are my ideas: 1.
> >>>> Linux PAM (authentication and single-sign-on) 2. LUKS disk
> >>>> encryption 3. OpenSSH 4. GnuPG 5. Web browser client cert
> >>>> (Chromium and/or Firefox) 6. X.509 certificate authority 7.
> >>>> Kerberos auth for work (not very familiar with this one) 8.
> >>>> OATH time and HMAC one-time-passwords
> >>>> 
> >>>> I have a TPM in my laptop, and access to an Aladdin eToken
> >>>> 32k 4.2b to play around with at work. I also bought a
> >>>> smartcard reader, and have been exploring GSM SIM cards and a
> >>>> Bank of America EMV (chip credit card). So far most of my
> >>>> success has been with the TPM, namely SSH keys [2] and the
> >>>> X.509 CA. I haven't been able to generate useful keys on the
> >>>> eToken.
> >>>> 
> >>>> I have (5) implemented against OpenDNSSEC's SoftHSM, although
> >>>> it fails all the requirements since it's a software solution.
> >>>> The value, however, is that I can isolate the key in a
> >>>> separate user and process, similar to ssh-agent or gpg-agent.
> >>>> The interface to SoftHSM is PKCS#11 which is common among
> >>>> hardware PKI tokens.
> >>>> 
> >>>> This brings me to my next idea: the Yubikey NEO [2]. It's a
> >>>> USB device that seems to have a bit of a following and
> >>>> support. Does anyone have experience and opinions with this
> >>>> device (or other hardware tokens)? The Yubikey NEO looks like
> >>>> it can integrate with most the applications I have.
> >>>> 
> >>>> I'm at a point where I can start writing a presentation about
> >>>> all this with some confidence. When's the next cryptoparty
> >>>> when I should have it ready by?
> >>>> 
> >>>> Thanks, Jesse
> >>>> 
> >>>> [1]
> >>>> 
> >>> https://blog.flameeyes.eu/2011/04/network-security-services-nss-and-pkcs-11
> >>>>
> >>> 
> [2] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
> >>>> 
> >>>> _______________________________________________ 
> >>>> cryptoparty-chi mailing list 
> >>>> cryptoparty-chi at groups.sshchicago.org 
> >>>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
> >>>> 
> >>> _______________________________________________ cryptoparty-chi
> >>> mailing list cryptoparty-chi at groups.sshchicago.org 
> >>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
> >>> 
> > 
> > _______________________________________________ cryptoparty-chi
> > mailing list cryptoparty-chi at groups.sshchicago.org 
> > http://groups.sshchicago.org/listinfo/cryptoparty-chi
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBAgAGBQJUnxtxAAoJEPMZXCkqgi71i+UP/jBi03gKGmcrEYOaHwF2hEjW
> KapmSj1k8lum5EcG0Ri5vEATaUgGW8kKWa2G0aiu6c7FmS6B3CAhxqN+5vcJIvtY
> 7aArWmtN/WUslGGk4rZAFoYOUJN9ZHyBHBN6XhBdLY/cfi6Jf8/EjfAlRDK2Hqg+
> meBLM1oVHpidbsMg2lsyzj/QjQ79WP2OCECdL+YrfSpO67Ksj2ol5HJEYZAyguM9
> CEbvfm5vFVeZtqDcZynyMe1HoEUeDChm694UZ9P1MHGnwsTW6SbfJ488TaLnzgzv
> eXjwurr847OsdfIRn3wHfW8iKhjBhULFd1IHSJrCFnY4FXGbDHlN8roEZcJG+NBg
> QKw8ROP46qZWaZvzz6nmko28ov/53fXBvPCRj7Ghs/I+h+fbW5TkHLLshRcVKZIu
> Qcl9SkRBK0sYXEk07dTkwYDePK3rNV2Wr7ZYXfAwbyL1wu9fBxCuoazc0XvXcIYU
> Ojt4DxVt1GPhdoWoXUsBPPilU5P89RTI7/QfgE4RULylnbtPQX4jI2qxmxKTHU1O
> L35nenZvpRUOcp7AaXwb8ZfwaKS5lor/YWK9pYkBuW3oXqF0lZUgodZRwPZQVh3a
> 7Ycgp6nzeNWGflWMAehroZxoOVWBPiQ14iCj/DnfRV+zeZ6OQv2NtWPXokOjYmik
> vy/luQmivTX/M7JWDoLM
> =+pPl
> -----END PGP SIGNATURE-----
> _______________________________________________
> cryptoparty-chi mailing list
> cryptoparty-chi at groups.sshchicago.org
> http://groups.sshchicago.org/listinfo/cryptoparty-chi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://groups.sshchicago.org/pipermail/cryptoparty-chi/attachments/20150221/dc46a7f1/attachment-0001.html>