On Thu, Aug 28, 2008 at 03:32:56PM -0700, Andrew Lentvorski wrote:
Is it possible to create an open source SecurID-like keyfob? Building the
hardware should be *painfully* cheap. I'm staring at a full 8051 with
flash from TI for under $10. It even does USB.
The RSA keyfobs presumably have two things:
1) Unknown time-based algorithm for generating the factor
The algorithm has been reverse engineered, and is fairly well
understood. If you implemented the same algorithm even the same
software would likely work. There would probably be legal issues if
you tried to sell such a device.
You might try searching the net. I believe there is a project to
create an open token.
Security-by-obscurity is always bad, but I'll presume that RSA has a good
algorithm somewhere. I presume that we could find some good algorithm
that's already vetted by the security community.
It's proprietary, but now documented. There is a 64-bit secret within
each key. The secret must be given to the host software so it can
verify the key sequence.
2) A seed value used to generate the sequence.
Effectively, this is the "shared secret". Presumably, you want something
like public key cryptography. The private key is stored on your keyfob
while the public key is stored on your server.
The question is: what algorithm?
On the keyfob side, we need an algorithm that can take the current time and
some private key and create a factor.
It depends a lot on how much CPU you have. If you have enough CPU to
do an MD5's it's easy to do with well-known easily understood
algorithms. Basically, HMAC(secret, time) is sufficient. HMAC is
designed so that most can be pre-computed based on the secret and only
the last part needs to change based on the changing timer value.
One the computer side, we need an algorithm that can take the public key,
the current time, and the factor and verify that the factor is correct. I
don't know how to do this.
The keys tend to drift. The host side code requires a pair of key
outputs to resynchronize. Basically it starts with last known time
offset the key had, and searches out from there to find the one that
matches. From there it assumes a new time.
If you use HMAC, you only really need one output code. If you find
the source to the reverse-engineered RSA algorithm, it should be
obvious why they need two.
BTW, the RSA in the company name has nothing to do with the RSA
algorithm they invented. The key algorithm is very different.
I'd start with google, though, since I'm fairly sure there are already
open source token systems out there.
David
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
