I guess this concerns only a few FlexOne and Apex Mega wearers for now, but it will concern Apex Flex wearers soon™.
Here’s a PAM module to log into a Linux box with your desktop PC/SC reader of choice using the Vivokey OTP applet and the Vivokey Authenticator:
Debian packages here:
Hey Rosco! Back with a banger I see!
I just released a new version that does away with the 6- to 10-digit TOTP codes that are valid for 30 seconds altogether.
Now Vivokey PAM directly asks the Vivokey OTP applet the full HMAC-SHA1, -SHA256 or -SHA512 hash (depending on how you set up the account in the Vivokey Authenticator app) from a randomly generated 64-bit challenge, and compares the hash returned by the implant with a hash it recalculates locally using the user’s registered secret.
This is much, MUCH more secure, as the keyspace goes from 106 → 1010 possible codes with a 30-second TTL to 2160 → 2512 possible codes valid only once in the PAM module itself and nowhere else.
In short, despite the name of the applet, Vivokey PAM now uses the OTP applet as a full cryptographic engine without any notion of timecodes anymore, and it’s basically impossible to abuse.
I’m not into this so excuse my stupid question, but this sounds like you have the secret on the PC, not only the chip. How is this more secure?
Well okay, I may have overstated it a bit 
But let me explain:
Firstly, re your question: indeed the credentials are on the PC. If you compromise the PC, it doesn’t matter what scheme you use: it’s defeated by definition. This holds true of any symmetric cryptography system (which is what OTPs are) since both the authenticator and the authenticated device must hold the same key.
But here I was talking about something else:
With TOTP authentication, the challenge (that is, the big-ass number you present to the hash algorithm to calculate a hash from using the shared secret) is the current time in chunks of 30 seconds. Meaning, for 30 seconds, the challenge remains unchanged. Guess the right code within 30 seconds and you’re in. And since TOTP codes are between 6 and 10 digits, there are “only” 1 million to 10 billion choices of code to choose from
What the new Vivokey PAM does now is, instead of using the time divided by 30 seconds as a challenge, it uses a completely random number each time it runs. So the resulting hash is only valid once. And instead of using a very small subset of the hash (the 6- to 10- decimal digit number) as a code, it uses the entire hash, which would have you guess 1 code out of an unfathomably large number of possible codes.
The size of the keyspace makes it slightly safer - only slightly because, practically speaking, even with 6-digit codes, it’s almost impossible to guess one code out of one million within 30 seconds - particularly since PAM throttles the number of tries per minute quite dramatically.
What truly makes it safer is that, if a bad guy was to sniff the traffic between your implant and the reader (with a Proxmark3 for instance, but also possibly with a compromised USB hub) and get the code, they can’t use it in a replay attack anymore.
The reason I overstated it is because the aforementioned hypothetical replay attack would have to happen within 30 seconds, and more importantly, some shady dude would probably be crowding your space with suspicious NFC or USB hardware, and you’d have to be blind drunk not to notice.
But hey, in theory, no more replay attack and a huge keyspace is much more secure
The reason I overstated it is because the aforementioned hypothetical replay attack would have to happen within 30 seconds
If you generate a new number (-> new hash) for every login attempt, then how would a replay attack be possible? I don’t think it is Anyway, nice project, thanks!
Ah yeah sure I thought you use it on some website and also have the keys on your PC which definitely would be dumb. Completely misunderstood what you’re doing here ^^
Now that I get what you’re actually doing, I see that too. Very cool actually!
That’s definitely in my threat model 
Right, I meant even with the TOTP scheme, you only have 30 seconds to do the replay. Sorry it wasn’t terribly clear.
That’s what TOTP is for: websites can’t very easily present a challenge to the token, so the shared challenge is the time - which works if the two devices are reasonably synchronized. Although to be fair, some really annoying systems exist to pass a challenge to the authenticated device, usually involving scanning a QR code with a cellphone. My company’s website to record working hours is like that and it’s a PITA.
But here it’s different: the authenticator is a PC and it’s talking directly to the token. It’s a full-speed, two way link, so there’s no reason not to exchange challenges and hashes normally.
Fortunately, the OTP applet works exactly like that under the hood. The whole 6-digit, 30 second code thing is just software dumbing down done on top of the real cryptography to make it easy for a human to type a small code within a reasonable time window. But Vivokey PAM can strip all that away and do proper cryptography just fine.
It’s not really PAM- or authentication-related, but I figured this had enough in common with the Vivokey PAM code that I added it to the PAM module. Also, I don’t really feel like spinning off yet another project just right now…
I added an option to vivokey_pam.py to use it with cryptsetup, to unlock encrypted LUKS volumes with an Apex implant running the Vivokey OTP applet.
It’s quite technical. Ideally you want to be somewhat familiar with cryptsetup to set this up. Nevertheless, it’s not too complicated. If you’re interested, check out the README:
