OK, so let's start from the beginning.

This stuff is roughly the same as what is being used by all Chip & Pin Credit Cards. In order to secure this stuff, most banks will invest in HSMs (Hardware Security Modules). These are devices that between 7k GBP (PCI version) and 35k GBP (standalone ethernet version). A handful of companies are sharing the big business that this represents: SafeNet and nCipher (until they were bought by Thales) being the main ones.

SafeNet is notable because their hardware is quite a bit cheaper than Thales', and they provide quite a few avant-garde features (such as USB smart card readers that establish direct connections to the HSMs). SafeNet also owns most of the US DoD market.

nCipher (now Thales) owns a good chunk of the European banking market. They are also implemented in a few big corporate environments (think biggest UK telco company, or biggest Ukrainian telco company, etc). Their hardware is quite a bit more expensive, but their support systems are definitely worth it. If you have problems and a valid support contract, you can be sure they will move continents to fix things for you.

A networked HSM looks like a blade server. You just put it in your rack, plug in the power and ethernet, and you're done (I'll skip the part where you have to create security worlds, which are the partitions in which the keys will be stored). They store specific keys in hardware, encrypt the files with those keys. The files contain your keys (the keys your applications will use). The primary advantages of HSMs are the security and speed they offer. If you try to open an HSM, it will basically "self destruct", and destroy the keys it contains. In terms of speed, HSMs can offer between 500 and 6000 1024bit RSA key generations per second. If you need 4096bit keys, speeds go between 60 and 500. In comparison, the fastest smart cards can only generate a 4096bit transaction in about 3-5 seconds. This means that in concurrent access, the slowest HSM could still handle 180 clients per second.

Now, imagine you have this big box that can generate and validate gazillions of transactions every second (and this is just if you have one box. More often than not you will see between 2 and 6 HSMs deployed). What do you do with it?

Well, first, your server generates a key. This will be the "master" key. All the clients (tokens) that will be associated with this server will have their keys deduced from this key. Well, actually, this isn't true; you have a bunch of keys, but I can't go in those details right now (need to wait for some of my notebooks, which are still being shipped from Australia). Understand that you at least have two master keys, one for the synch part (OTPs, One-Time Passwords), and the async part (CRs; Challenge/Response).

Your server implements a few features. The more elaborate servers (such as my previous company, ActivIdentity's 4TRESS AS, acquired from ASPACE, and deployed at most UK banks) provide full customer help-desk features, allowing to authenticate the user through password, seeded password, memorable data, seeded memorable data, OTP, CR, oAuth, session transfer, etc, etc, etc. But for our use-case, let's imagine that the server only implements OTP and CR authentications. The CR should also provide the option to have user-provided challenges, or server-enforced challenges (I will go further into this at [1]).

Now, let's talk about the clients (this can be hardware, or software). There are a number of companies that offer what is called "soft-tokens" in the industry. The offer the same features as hardware tokens, but obviously aren't as secure. Just search "RSA" on your iPhone's app store, all the major security companies have them.

The client has a number of keys, too. One for async, and one for sync authentication.

There are two major ways of doing authentication. OTP (sync) and CR (async), but they differ vastly in terms of algorithm.

If you were to look at the sequential output of the auth sync, you could sum it up as (where f is function, and s is seed):

f(s), f(f(s)), f(f(f(s))), ...

What this means, is that the next iteration of the output is based on the previous output. This also means that the output is predictable, if you were to know the key, and the seed.

The seed itself is composed of a number of things, but most commonly there are four things that are used (in order of most-seen):

1/ sync key (usually 3DES)
2/ time counter (32bit based), see [2] for more information.
3/ event counter
4/ PIN

So what is this "output" made of? What is an OTP? Well, the length can vary, obviously. But generally, it's between 8 and 10 digits (to accommodate for the size of the screen). If you generated a bunch of OTPs, you could probably notice that one of the digits increments quite regularly. Maybe even two, but in a different order. If your device uses an event counter, then the last digit of the counter value (say the value in the device is 3829) would be the second digit of your OTP. The first digit of the OTP would be the last digit of the clock counter value. This is so that the server can compute a handful of "most likely" OTPs, in order to counteract the clock drift and people playing with their device. Remember, everytime you generate an OTP, the event counter is incremented. If you generate an OTP 20 times, but never send it to the server, the server doesn't know where you are. This is just to prevent a too high load on the server, and limit the number of computations necessary.

Now, what are the last 6 or 8 digits of the OTP made of? Well, that's the actual OTP. It's the actual "random number" that allows the server to authenticate you.

I don't remember exactly which method is used to generate this number, but it could be any hashing method of any secret you want.

Let's say for fun that we use md5 (yes yes, I know how insecure it is, bla bla bla, just an example), of a concatenated string of the secret, the auth key, the total value of the event counter, and the total value of clock counter. Convert it to decimal, and divide by 2 until you get 8 digits.

So in order to get an OTP, you would have (in PHP, because I can't be bothered, it's nearly midnight. Also please note I'm just writing this as I go along, so there will most probably be typos):

And tada, there you go. You just wrote a client that generates OTPs. Obviously, your server needs to understand this, and be able to do exactly the same in order to authenticate your user, but this really is just it. Now, I have no idea how secure the above is. There probably is a reason why Vasco is able to sell their devices at $10 a pop.

There is a very important bit about the above algorithm, the fact that a new key is being deduced after every generation. What this means is that even though 3DES could be broken in just a few hours (last I heard, 3DES could be broken in about 8 hours), this really doesn't matter. The key is archaic as soon as it has been generated, so what's the point of trying to crack it?

Now, when it comes to CRs, it really is roughly the same stuff. The only difference is that the key never gets updated, and you don't use neither an event counter, nor clock counter. Again, as I said previously, this doesn't prevent the server from enforcing time-based challenges, which can decay very rapidly (a few minutes). However, from a device perspective, it doesn't change anything.

[1]: There are two likely scenarios, where you want to authenticate a user, or when you want the user to authenticate the website/prevent MITM attacks. Say you want to ensure the user has the token, you ask him to give you the response to "7762". This is when the server enforces the challenge, because you need to be sure there is no CR replay. When you want the client to authenticate a transaction, you ask them "please give us the challenge to the 3 last digits of the target bank account, and the 4 last digits of the transaction amount".

[2]: I only have intimate knowledge with one specific vendor, so I don't know how it goes with others, but the implementation I have seen was a 32 bit clock that incremented every half second. We would mask the 8 least significant bits of that clock so that the Clock Counter would only increment every 1m 32s (or was it 2m 32s? Can't remember).

Sorry I had to skip over some details, but the girlfriend needs the computer off.

Hope this helps,

FYI, got my youtube account back. It's a slight ordeal finding the right recourse... and from the looks of Google forum comments it's been a HUGE problem the past year or so.

And once again, I curse the fact that there is no Thanks button in Off Topic. Thank you very much for providing us with that insightful write-up.

Regards,
Chris.

first things first:

do you have ssh server installed?

e: btw thanks for the reminder to change passwords once in a while

Hey Ossipena,

I assume you are asking about the SSH Server on my N900, The answer is Yes, I do, and the password for both root and user are none default, both include letters digits lowercase capitalcase.

+ Phone is mostly not connected to internet,
When it is, it's either at home wifi, where I have a router blocking port 22, or 3g where I get a private (sadly) ip address... and not a public one. (again sadly...)

I just wanted to check that because it would have been the most obivous source for hacking. it requires something as complicated as:
are there btw open security holes in ssh software available to N900?

Well, the button is missing, so I'll have to do it manually: Thanks!


I have a RSA.pas in my projects folder. I have it implemented for registering software and for encrypted chat. I know it's useless, but back when I played with the idea a 376 bit key was pretty nifty. Key exchange was dynamic, generated at start of chat. Also, user could re-sync keys at any time during the conversation.

As an old cartoon character would put it, cool, but useless.

And that's why I invested in a water cooling solution for all my PCs. Along with a soft touch kbd, a quiet mouse and fully-enclosed headphones, I could shame a mouse in a church.

I went from shut-down-everything to letting my HTPC on, overnight, 1.4 meters away from her head. That is, assuming you don't defrag or check the CD.

Man those optical drives are loud.

Oh, and, it also allows for some sweet performance boost. My mouse of a PC boasts a 4 GHz quad and dual video card.

Everything is cooled by 2 120mm fans, on low (800-1200 RPM, heat sensitive).

Actually, I have a macbook pro, so quiet enough to use anywhere too. It's just she was jealous

I wouldn't know

Start saving. :)