DIGIPASS GO3… Here’s everything I know
First, some historical context must be in place. Back to 2006…
After having to live with idiosyncrasies surrounding technology/business decisions around me, I went on a personal crazy quest regarding VASCO’s DIGIPASS GO3 crypto token.
It turned out to be really bad for my health, augmented my general lack of spare time, and produced no practical results, besides having to deal with emails from all around the world, ethical issues, and, fortunately, a not so angry vendor (in fact, its representatives were very kind, trying to understand the whole mess, and settling things down).
Everything happened because I decided to reverse-engineer (RCE) the following device’s algorithm for OTP generation:
It was a really stupid waste of time, and the endeavor was not worth it. I expected the security/crypto community to analyse the Bugtraq published “C++” implementation (more about this in a glimpse of a second), and provide better understanding regarding the mathematical structures behind this widely used token (back then, I believe, it was the most used OTP hardware in Brazil; and although I have no official sources/numbers to back this feeling, it was a time where OATH and HOTP were very young promises, and VASCO’s and RSA’s tokens abounded everywhere).
The RCE process was as nuts as it can get. Cryptographic software, by its nature, is complex. And good crypto software is also heavily optimized, what makes things even worse when disassembling is involved.
I was able to reconstruct a working (pseudo) C++ implementation of the 3DES_112 based digipass algorithm. Notes from original post:
(…) generator was able to predict an “otp” collision, within ~10 days range (…) as DES is free, I guess the patents held by the company protect only the synchronization side of digipass. Just a theory (…) a brute-force approach was used instead, because I believe in law (…)
A few remarks. First, the aforementioned “pseudo” from the text doesn’t mean the code was non functional. It worked pretty good. The collision found - by itself - is a statement of the implementation correctness. When I said it was “pseudo” C++, I was trying to be nice to myself… The code is horrible! Ugly. Scaring. “Scripting”/throw-away C/C++, because I was in a hurry to test things up. Please, don’t use it! The source was nothing more than an almost 1-to-1 translation from machine to high-level code. With just a small structured layer over it. I mean it. I think this was one of the (minor) reasons behind community lack of interest (just a guess).
Second, I was not trying to hurt digipass reputation in any way. Nor was trying to threaten VASCO’s intellectual property (far from it; I don’t believe I could have accomplished this, even if I tried *hard* - and that was not the case).
I was careful enough to not even touch some parts of the proprietary implementation, and decided to use a brute-force approach instead, when OTP synchronization was needed (a better decision, cause I didn’t know what patents were held for that code). I think this was one of the reasons behind VASCO’s kind/diplomatic position (another guess).
…and now, let’s move forward to 2012.
Don’t get me wrong, it’s not that I don’t like tough personal challenges. I love them. A lot! The central point is that I don’t “stuck” myself anymore, trying to prove things that make no sense. Or doing things just for the sake of doing. Or because I can. Or even cause I know they’re possible. For me, it’s irrelevant nowadays. I’d rather spend time studying/working, with my family/dogs, and/or practicing BJJ. And this brings me back to the post core idea: here’s “everything” I know about digipass, 3DES_112, and OTP tokens in general. Here we go!
a) fcollyer, do you have any updated code, secret, or knowledge about digipass? - No, I don’t have anything about it.
b) And what about AES based digipass tokens? - See answer to question [a].
c) Could you please help me integrate the published implementation with [technology-XXX-goes-here]?! - Unfortunately, I can’t. I don’t endorse that kind of thing. If you wanna use digipass tokens (for any reason), please consider licensing the software (it’s called VACMAN Controller). Damn, I don’t even endorse my own published “code” usage! (see the comments in the first part of the post)
d) And what about 3DES_112? Is it still good to use this keying option, specially in OTP implementations? - First things first. Since January 1, 2011, NIST has withdrawn 3DES_112. If you can, stick to better/newer alternatives, like 3DES_168/AES. I prefer HOTP based implementations, but it’s a matter of taste. HOTP is open, uses an HMAC based (flexible) core, has known truncation/decimalization method (with well defined mathematical bounds), and implementations are widely available right now. As a side observation, I don’t want to scare you… but if you are really worried about 3DES_112 and OTP generation, a much better/worse concern is 3DES_112 and EFT/EMV! Believe it or not, 3DES_112 is still one of the financial transactions’ working horses. Worldwide, even for markets that already use EMV. Get over it… life is beautiful.
e) Can you recommend a good token provider/vendor? - As a matter of fact/principles, I try hard to avoid messing with these mysterious market forces. Whatever is good today, may not stand for itself a week from now on. VASCO, RSA, Authenex, whatever… - I think they provide good/bad enough OTP tokens for general purposes. I don’t really care. So, no, I can’t endorse any one of them more than the others.
f) Was VASCO’s formal response on Bugtraq technically correct? Can you explain further? - Of course! But first, one more clarification: I never said that “the algorithm implemented by Digipass GO-3 uses an encryption algorithm with a short key length“. Someone else said it (I worked on the realm of 3DES_112 only). Here, VASCO is right regarding the need to provide these tokens for “backwards compatibility with legacy applications“. But the one who stated that DES-based tokens would be prone to brute-force attacks was also right. Going back to the official response. In fact, they were (almost always) technically correct when they affirmed that “the security of VASCO’s strong authentication products only relies on the secrecy of the cryptographic keys involved“. The company even evoked the sacred Kerckhoffs’s principle. They were also right here. But that’s only part of the story. It’s perfectly possible to use “only standardized cryptographic algorithms that have been subjected to public scrutiny by experts” (like 3DES/AES), in a totally proprietary way, with unknown key derivation functions, secret truncation methods, flawed crypto protocols, and subject to other problems like side channel vulnerabilities. The lesson here: always take statements from companies (specially security ones) with a critical mindset.
g) What did you use to reverse-engineer the code? - That’s a good question, because it allows me to answer in general. In the beginning of my programming career, I used to program in Win32. I’ve done a great deal of this. Dlls, ATL, COM, MFC, services (argh!)… Not that I don’t like it anymore. For almost 15 years, I’ve been an enthusiast of GNU/Linux. And I’m very happy to make a living doing Unix programming 99.99% of the time. But to study/practice state-of-the-art RCE, Windows is almost unbeatable. And this is so, I think, because of its proprietary philosophy/lineage/nature/ecosystem. The tools of the trade were developed to evolve with the operating system (and protection schemes found on software made for it). In the past, I used SoftICE all the time, the debugger for Windows platforms. But it’s been dead for so long. A good user-space alternative is OllyDbg. The disassembler of choice is still IDA Pro. Every now and then, I use these tools. They’re amazing, and worthy of study (or paying for, when necessary). I recommend them for every serious programmer.
After so many years, for me (finally), this subject is now dead. Let it R.I.P., please. (but let me know if any important question is missing from the little FAQ; I’ll make sure it gets updated)