Desktop OTP display using Yubico Authenticator and Apex Flex

[jens]

it may have to do with memory. I previously had ndef 16 installed and am now testing with ndef 1 and now it works

[amal]

ok that is good feedback… what does your apex manager indicate for free memory space?

also even if it is due to memory we should return a proper error… otherwise you might think you’ve saved the key when it’s not actually saved!

[amal]

making some progress…

but first we need to push a new version of apex manager up… then we will update the otp applet on fidesmo… but… the yubico desktop app removes codes from the screen as soon as you remove your implant from the reader… which is lame. looks like we will have to make our own apps so implant users can more easily use it… basically by creating a timer so the codes are removed 30 seconds after they expire and not immediately.

[StarGate01]

Good news, the Fidesmo backend has been updated to deliver the new version of the applet with a Yubico Authenticator compatible AID.

On desktop it works out of the box, on Android you need to install the HMAC-SHA1 (which has also been updated to install using a slightly different AID) applet as well (it does not have to be initialized though), until Yubico fixes this bug.

Starting with the most recently released version v1.2.29 of the Apex Manager App, the App is now able to also read the new compatible AID of the OTP applet. Special thanks to @hoker !

If you already have the OTP or HMAC applet installed, you need to re-install them using Fidesmo, sorry. Make sure to back up your keys.

[jens]

Nice! It works fine with ios but when i trying to add a code with apex manager the app craches. It is not a big problem for me becourse i using yubikey auth on ios. Generate and push keys to hmac works fine and read otp:s configured with my main device (iphone)

[StarGate01]

Thanks for your testing! Are you able to share a QR code or OTP string which (reproducible) crashes your app, or a logfile (e.g. via logcat)? @hoker might be interested.

[SteffanDonal]

Awesome! Can’t wait to update.

As an aside though, given that it’s not possible to export keys off the applet, does anyone have a recommendation for backing up?

So far my best idea is just to take copies of the QR codes apps give you and store them in a password manager.

I’d love to see some way of exporting off-device, or even perhaps a “pre update persist” function that creates an encrypted package of all stored keys that only the implant can restore.

[caj380]

@StarGate01

Make sure to back up your keys

How can I do that? I want to upgrade, but it would be great if I could export all my codes so I don’t have to re-add them all.

[StarGate01]

Once the keys are written to the authenticator, there is no way to extract them, by design.

I usually back up the secrets which are encoded in the QR codes, or even the full text of the QR code (otpauth://totp/?secret= …) (see e.g 2FA QR Code Generator). I agree that adding them all back manually is annoying, and I am facing the same problem.

I will probably write a batch import script which is able to to read in a backup of OTP secrets and setup the applet. For the time being, you have to do it manually.

If you don’t have backups of your secrets, you have to re-register the key with every service.

@SteffanDonal

a “pre update persist” function that creates an encrypted package of all stored keys that only the implant can restore.

That is an interesting option, but comes with a few security challenges. Usually the secret keys should never leave the chip.

Segregating code and data is possible in theory, but requires some setup and careful implementation.

@SteffanDonal

So far my best idea is just to take copies of the QR codes apps give you and store them in a password manager.

Thats what I do as well. The script I envision would parse a e.g. KeePassXC database for string which match the otpauth:// scheme and then write these credentials to the applet.

[caj380]

I jumped the gun and re-registed every service. Didn’t think to read your comment first. Otherwise I could have screenshoted all my QR codes. Oh well, I’m sure I’ll have to do it again at some point. Thanks @StarGate01

[amal]

@StarGate01

Thanks for your testing! Are you able to share a QR code or OTP string which (reproducible) crashes your app, or a logfile (e.g. via logcat)? @hoker might be interested.

I’ve identified a bug and reported to @hoker already. My hunch is this was the first time @jens approved the camera in the app. I noticed that when I do that, the app crashes when I try to write the key data to the chip… but only that first time I authorize the camera. After that it works fine. Odd bug.

@SteffanDonal

As an aside though, given that it’s not possible to export keys off the applet, does anyone have a recommendation for backing up?

In theory you should be printing out screenshots of the QR codes and storing them offline in a paper safe… that’s the best way.

@SteffanDonal

I’d love to see some way of exporting off-device, or even perhaps a “pre update persist” function that creates an encrypted package of all stored keys that only the implant can restore.

This was considered actually… but difficult to make secure and also a lot of work to be honest… but I am seeing a point to it now with all these applet updates. Still, there probably won’t be another major applet update for a very long time… if ever.

That said, @StarGate01 we do need to do some more testing for 17+ keys stored… Apparently @jens was bumping up against an odd error on yubikey and apex where you simply can’t write more than 15-17 keys … it will seem like it’s stored but won’t be. That’s a terrible failure mode if you believe your key has been stored. Can we run a python test script to just brute force shoving keys into the chip and then running a code gen command to see how many actually got stored? If there is a limit, then we should figure out at least how to return a proper error for that condition.

[SteffanDonal]

@StarGate01

That is an interesting option, but comes with a few security challenges. Usually the secret keys should never leave the chip.

Segregating code and data is possible in theory, but requires some setup and careful implementation.

My line of logic here was, “Given that typical authenticator apps allow “account transfer”, despite going out of their way to make the raw data hard to access once a given token is registered, having a way to do this on Apex should be reasonable. Particularly for this specific need, only the applet needs to see the content, so it could be encrypted before ever leaving the chip”.
That said though, I haven’t yet started playing with applet development, so I’m probably missing something about the architecture of trust there

@amal

This was considered actually… but difficult to make secure and also a lot of work to be honest… but I am seeing a point to it now with all these applet updates. Still, there probably won’t be another major applet update for a very long time… if ever.

Yeah, I understand. Regardless of my thoughts, having physical backups of access tokens is good practice. So, once “update & polish turbulence” is done, this won’t be an issue worth solving.

@StarGate01

I usually back up the secrets which are encoded in the QR codes, or even the full text of the QR code (otpauth://totp/?secret= …) (see e.g 2FA QR Code Generator). I agree that adding them all back manually is annoying, and I am facing the same problem.

I will probably write a batch import script which is able to to read in a backup of OTP secrets and setup the applet. For the time being, you have to do it manually.

I think it’s possible to make this much less painful. The Apex application should be able to parse otpauth text directly:

1. “Add from clipboard” - what it says. Apex Manager reads the clipboard when this button is pressed, adding all otpauth URIs found.

2. Apex Manager exposes a text share target. Both of the KeePass Android apps I use allow for direct editing/viewing of a given otpauth URI, so you can select it as text. One of the options you get when doing that is “Share” - another possible input to make this process easier.

I would like to figure out a convenient way to create backups of access token keys - as it is right now, I have to take screenshots/photos of the QR codes and trust some random QR reader not to recognise/steal it when I create the backup. I would feel better about the situation if the Apex app would allow me to “export backup” during token loading - even if “export” really means “copy to clipboard at my own risk”.