Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Secure ID for SL

Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
06-27-2008 16:20
From: Ceera Murakami
Capturing the ever-changing codes over a long period of time still won't get you a way to emulate the key generation in software. The algorythm and the private key that generates it are not part of the six digits that you keylogged. It's hard-wired into the key tag.

If we were discussing stealing the six digits of log information, you would be correct.

This is, however, not the case I'm presenting. :)

In a way, this is like suggesting that because I have a MAC address tied to my computer's hardware, that I can't have my MAC trivially stolen. Because the address or key is used in software, or the hashes it creates are visible to applications running on the client's machine, the private key is still fair game.

The obvious difference is MAC addresses are given in plain.


From: Anthony Hocken
Steal the private key from who? The user can't get access to it - it's embedded into the device, and if the server is compromised then all bets are off anyway.

Theoretically, since the device needs to authenticate against an application running on their PC, all one needs is bad authentication code at the application layer of the machine running the device, and the security will be compromised.

Similarly, a hardware attack from code running on Ring0 of the infected machine could also be effective.


I don't have one of these tokens myself to test this (I use RSA in software), so instead I'll link three papers on how to successfully implement attacks on these devices.

http://eprint.iacr.org/2003/162.pdf
http://eprint.iacr.org/2003/205.pdf (improvement of the previous method)
http://malpaso.ru/securid/initial_securid_analysis.pdf (second opinion using hardware sniffing tactics)

The short version (skipping all the math and reading) is it can take as low as two days to bruteforce one of these tokens, or simply enough observation of the application itself to deduce the key, no "wifi-sniffing" required.

The fun part, of course, is that one can root your box and use your own hardware against you, by distributing the task of cracking the key to your machine. :o


As such, my point still stands. It's a great idea, but not a method that'll prove any more "secure" for the user over time, given enough propagation of these devices and false security claims.

And I must credit the OP for acknowledging this to be the case outright.
_____________________
---
Anthony Hocken
Registered User
Join date: 16 Apr 2006
Posts: 121
06-27-2008 18:22
From: Jeffrey Gomez

I don't have one of these tokens myself to test this (I use RSA in software), so instead I'll link three papers on how to successfully implement attacks on these devices.

http://eprint.iacr.org/2003/162.pdf
http://eprint.iacr.org/2003/205.pdf (improvement of the previous method)
http://malpaso.ru/securid/initial_securid_analysis.pdf (second opinion using hardware sniffing tactics)

The short version (skipping all the math and reading) is it can take as low as two days to bruteforce one of these tokens, or simply enough observation of the application itself to deduce the key, no "wifi-sniffing" required.


Just to clarify on the Yubikey. Your mention of RSA vulnerabilities don't apply to this device. The Yubikey generates 128-bit codes which are encrypted using industry standard AES which hasn't been broken.

With the Mac address, as you know, they're designed to be read and shared. Even over encrypted wireless networks, which is why Mac Address Filtering is next to useless for security. Even legitimate devices like network bridges can spoof Mac addresses. So not really a good comparison to a key which is embedded into a device which at no point is read by the computer, user or anything else.

That's the whole reason for the device in the first place - to conceal all this trickery away from the computer. It generates a code, using a cipher which has not been cracked, and this code passes via the PC on to the server, which decrypts it using its own key and checks that the timestamp stored within is valid.
_____________________
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
06-27-2008 19:46
From: Anthony Hocken
Just to clarify on the Yubikey. Your mention of RSA vulnerabilities don't apply to this device. The Yubikey generates 128-bit codes which are encrypted using industry standard AES which hasn't been broken.

Since we're now talking about a different implementation of the same concept, I would still question hardware-based attacks, man-in-the-middle, and deterministic attacks against the factory's PRNG, in much the same way I question certain implementations of DRM.

It's not a question of breaking AES security (which is excellent, and widely used), so much as crafting an attack on the weak points of the chain.

If there *are* no weak points, or in this case, any way that human error can break the chain, then I'll agree that security will be significantly improved. Blanket distribution of RSA tokens won't do that; crafting a sane security chain from beginning to end, will. :)



From: Anthony Hocken
With the Mac address, as you know, they're designed to be read and shared. Even over encrypted wireless networks, which is why Mac Address Filtering is next to useless for security. Even legitimate devices like network bridges can spoof Mac addresses. So not really a good comparison to a key which is embedded into a device which at no point is read by the computer, user or anything else.

This is a straw man meant to prove that just because a key is tied to hardware, it does not mean it cannot be easily ripped off.

MAC addresses are far more promiscuous than an RSA private key, I agree.


From: Anthony Hocken
That's the whole reason for the device in the first place - to conceal all this trickery away from the computer.

Absolutely. My concern is that these devices do not conceal *enough* of this trickery away from the computer (or the user) -- to which the stronger answer is to not have the weak point in the security chain infected in the first place.
_____________________
---
Lee Ponzu
What Would Steve Do?
Join date: 28 Jun 2006
Posts: 1,770
06-29-2008 07:29
I hire an in world body guard service. 24x7, they have guard bots in world that look for me to login. When I do, they TP over to where I am (they are invisible) and interact with me. Using AI the bot determines whether it is really me at the keyboard, or someone who has stolen my av.

And now with the coming world-wide greater depression arriving, it will be easy to hire real people to provide the same service, or if you end up in the impoverished masses, it will be your only remaining job opportunity. Sort of like Serfdom in the middle ages.

Illusion is the only reality.
_____________________
So many monkeys, so little Shakespeare.
Anthony Hocken
Registered User
Join date: 16 Apr 2006
Posts: 121
06-29-2008 07:58
From: Lee Ponzu
I hire an in world body guard service. 24x7, they have guard bots in world that look for me to login. When I do, they TP over to where I am (they are invisible) and interact with me. Using AI the bot determines whether it is really me at the keyboard, or someone who has stolen my av.


Firstly, wow! Secondly, if the bot's challenge/response goes unanswered, then what? Presumably by the time they've managed to alert you alot of damage could have been done.
_____________________
1 2