I had this moving dot barcode reader and it gave me an idea. It is recognized as a USB keyboard, and it just works out of the box without any software on any computer.
I imagine a glass bead blinky implant that when it powers up, it waits a second, and increments an internal register. Then it blinks out the otp code in Code39 with a red led (surrounded by “*” codes to the barcode spec).
If you take the barcode reader, break the vibrating magnet thing and swap the laser for blue, add a filter to the sensor. The barcode reader will now type your otp. The wedge could simply become a Frankenstein merger of a power source for NFC and an existing off the shelf barcode reader board that has been stripped of its original plastic housing.
Security:
Set up something on the chip so that the secret value can be saved, overwritten if given a valid series of expected codes, but never read.
Also relevent: The method of powering up the device is magnetic pairing, the method of sending the otp, is arbitrary coded light pulses. Code 39 is merely an example, effective means of transmitting numbers is arbitrary. Morse code, count the number of blinks and pauses (pulse dial), use dmtf modulation, use Reed-Solomon error correction, etc.
HOTP is TOTP but instead of an incrementing value it is the time that adds some pinache to your secret. This standalone file works well. NFC can’t keep time, but it can keep count.
My only question would be, if you are going to the trouble of powering the device with NFC, why not send the data this way too? What is the benefit of reading the data optically? Seems to add a lot more complexity if you ask me.
It wouldn’t be hard to read a value from a chip, increment it (or generate a new one based on it) and write the new value back. We already have USB keyboard wedges that will enter a password either read from a chip, or determined based on the UID of a chip.
This would basically be generating an HOTP password based on the value stored on a chip.
The Apex can manage TOTP so with the right chip this is doable, but if you are willing to make the reader an integral part of the solution then it wouldn’t be hard to use any NFC chip as a store for the current HOTP value.
Absolutely negative. The value must increment once every read and display cycle. This is not some sort of chalkboard anyone can scribble on and glean information from.
There are two kinds of NFC chips, those that are smart cards (like the Apex) which are capable of running software, and those that are basically just data stores.
I was talking about how you could use a reader + data store combo to achieve the goal. The alternative is to use something like an apex, which can run HOTP software itself (or indeed TOTP).
Neither requires the complexity of decoupling the output from the power source.
Reading data optically is long distance capable. Power transmission isn’t quite there yet. You can read a blink code from across the room. TV remotes from the 90s demonstrate that, haha. Why not use a really good information transmission method with a really good power delivery method, with a demonstrated secure, in practicable use, algorithm?
But you still need power to light it up, which has to be close. I just don’t understand the point of doing it optically instead of doing power and data over NFC. That would also allow you to sue any reader instead of a NFC power source and heavily modified barcode reader.
If you can read it across a room, what’s to stop someone else from doing the same? That doesn’t sound incredibly secure to me.
Don’t get me wrong, I love the idea of blinkies being able to transmit data long distance. It’s novel and cool. I just wouldn’t use it for something that shouldn’t necessarily be public information.
I think some of the design ideas are a mix of fun and fancy. Having someone use OTP of some form over none is an improvement. Making the code base as simple as possible, transparent and easy to read might make 2FA, I dare say, approachable, and interesting.
SMS has been presented in talks at defcon as insecure, as a little bit of social engineering can grease a carrier into issuing a phone on your account, which can be swapped in for your SIM, so an attacker gets your OTP. Or something like that. https://www.ieee-security.org/TC/SPW2020/ConPro/papers/lee-conpro20.pdf
So there’s no confusion, this is the same exact protocol implementation of Authenticator that you scan a barcode with your phone to get the generator secret into your app. These authenticator apps usually display a code on screen, and you might physically key these codes in. The relevant concerns you presented are in the original use case. A person could feasibly read your codes from across the room.
Perhaps yourself and others might make your own spinoffs? If blinky visible light is bad, maybe use IR, or develop a small NFC library, or use something unique to you.
I’m working on adapting some open source pam code to this first iteration, and if there is some degree of interest I might develop NFC into it or some other means of transmitting HOTP codes.
This is a fair point. I tend to use a security key (Yubikey) or Duo Push when possible, I’m not a fan of the otp codes, especially SMS.
Speaking of attackers getting access to OTP codes, my mother was actually recently conned into giving hers to someone. She was trying to sell items online, and someone “buying” them wanted to “verify the she always real.” So she said they told her to give them the “Google Verification Code” that they texted her. 99% sure they were attempting to con her out of her OTP code. I immediately had her change her password and sign out all devices. Luckily she doesn’t use her Google account for much.
I’m able to run a (really) tiny implementation of the OTP generator in C++. I’ll write the code to represent the 6 digit code in Code39. Then finally, I’ll be porting it out to Arduino using an EEPROM counter instead of the unix timestamp as it is currently implemented.
I bought a few of the ATtiny84A chips which are versatile (and in stock). There’s a 15UFBGA which is super small, which can be the eventual target to get it in an implant.
Counting in EEPROM is tricky. I didn’t want the same byte to get rewritten every time the chip powers on, and I was willing to store numbers inefficiently at the expense of storage utilization. Here’s the explanation to my wear leveling algorithm.
I found I could use a ring buffer to store a big number in a Linear Feedback Shift Register (LFSR). Each count rewrites two bytes. The trick was to have a bit reserved to identify the “head”, and increment the LFSR by the same number of counts as is reserved for the base of the character set used. This way the number of rewrites is kept low. The ring buffer can be arbitrarily larger than the required 8 bytes.
The chip seeks out the lowercase letter, and stuffs it and the following characters into a maximal length Galois LFSR. The chip increments that and writes the result back to the EEPROM, now offset by a byte position.
What? Yes that is a barcode scanned from an audio recording of the “sound” of the led. I used an analogWrite 50% and 0% to basically On/Off Key it. It’s far from finished, but the finish line is visible.
Clocking in at 5390 bytes including bootloader, yes, it will fit on the ATtiny84A!
I added four symbols of Reed-Solomon error correction to the end. Means you can have at most two characters lost and you can still get a good read, or whatever. I wanted to be darn sure of a good read before sending keystrokes, and possibly locking a user out.
So I have been having issues getting the SHA1 to work on the ATTiny, but just about any other board works. That’s what is at the core of the HOTP. And this is precisely the chip I want to be able to use, because it’s small.
For now, I’m going to allow the ATTiny to not work, for now, and drive ahead on other chips that do not cause me bewilderment.
Now to make a USB keyboard emulator that can read it, and power it.
