[ltp] using fingerprint reader for encryption or ssh login?

[lists]

Jiang,

you could also get yourself a usb hardware crypto token (e.g. aladin's
etoken, or rainbow's ikey 3000**, both are supported under linux). The
tokens implement crypto routines for generating, storing and using
keys that never leave the token. There's integration with mozilla for
signing mail, pam for authentication (i think), etc.
see  http://www.opensc-project.org/ for more details.

of course, you need a pin to authenticate yourself to the crypto
token, and that would be vulnerable to os-level attack (though abusing
the pin requires physical access to the token).

good luck!
nessim

** i have nothing to do with either, nor any specific views on the
companies. Other tokens may also be available now, a few years ago
when i dealt with it, those were the only 2 tokens "supported" under
linux.

On 21/11/2007, Jan Kundr=E1t <jkt@gentoo.org> wrote:
> Jiang Qian wrote:
> > Thanks a lot JKT for your detailed explanation. I do have a trusted chi=
p
> > on my thinkpad T43. I'll trust them alright.
>
> An important point to raise here is that if there's any flaw in the TPM
> chip, you can't defend against it. If any of the companies producing it
> (from chip designers to silicon manufacturers) added a backdoor, you're
> screwed.
>
> > How to do hardware crypto using tpm under linux?
>
> No idea except [1] and links from that page. I don't use it myself
> (yet?), sorry.
>
> > And what is the advantage of a TPM chip over the following method I'm
> > considering: I have a usb key with encrypted key files. Only when I nee=
d
> > to decrypt a file, I plug it in.
>
> Let's assume the TPM chip is really secure and well-designed. (I'm not
> sure that you can verify that yourself. If you can, I guess it'd be far
> more difficult than verifying a corresponding SW-based solution.) Now
> the difference is that the encryption key never leaves your TPM chip.
> The TPM generated it and (again, supposing it isn't malfunctioning) it
> will never leak it outside of its secure domain.
>
> Now if you want to "use the key", it's probably becasue you want to sign
> some data or decrypt them. The application you're using now asks the TPM
> like this: "Hello TPM, I've heard you have a key 0x1234, right?" - "Yes,
> I do" - "Great, please, use it to sing the following data:
> 0x33663366..." - "Here you are: 0x99887766...". See, the secret key
> never leaves the TPM. When signing data, your "signature key" is the
> secret stuff you want to protect.
>
> OTOH if you wanted to use the TPM for stuff like HW encryption, it'd
> work like this: "Hi TPM, please decrypt following data that I just read
> from the disk: 0x112233..." - "Sure honey, here it is: 0x998877...". (I
> guess there'll be some performance issues as well, so it might be worth
> to use TPM just for decrypting a real key that you'll use for doing all
> crypto stuff with host CPU. This method will protect you only from
> someone getting a raw dump of your hard drive, not against someone who
> can break your OS.
>
> The important point here is to decide *what* you want to protect -- the
> data on the disk, or the key itself? Surely the key is unknown to the OS
> so no attacker can steal it, but the OS still sees the real plaintext of
> data. There's *nothing* you can do to prevent this.
>
> > I guess in this case a hacker can
> > syphon off the decrypted key from the memory or just replace the gpg
> > binary in my system. How is TPM different? Why can't he replace the
> > binary of whatever program I use to decrypt what's on the TPM chip?
>
> If the question is "can the attacker retrieve the key", then "no, he
> can't (provided the TPM chip is safe)". OTOH if you wanted to ask "can
> he see my data", then the answer is "yes, when he breaks your OS, he
> can", and "no if he can read all your hard drives and USB sticks, but
> can't break the OS".
>
> [1] http://thinkwiki.org/wiki/Tpm
>
> If anything in this mail is rubbish, sorry for that. I have no extra
> cryptography knowledge.
>
> Cheers,
> -jkt
>
> --
> cd /local/pub && more beer > /dev/mouth
>
>
>