Feature Request: OTP, One Time Password/Code

[mateMathieu]

Dear InfiniTime devs,

I would like to suggest a feature in the development of your watch operating system. Including a OTP function right inside the OS can represent an appealing feature to consider.

The use of OTP is increasing as security tools are enabling often these type of verification, and what is more convenient than your watch to provide you the one time password that you need on a short notice?

Since it is an important security feature including it in the main code would be an insurance that it is up-to-date.

One example can be helpful on most operating systems. FreeOTP (iOS and Android apps developed by Redhat).

Finally, scanning the QR code from your phone and transferring the credentials to the watch would make it very simple.

Cheers

[Avamander]

FreeOTP

Just mentioning that it isn't being actively developed or maintained, AndOTP is probably a better choice.

Finally, scanning the QR code from your phone and transferring the credentials to the watch would make it very simple.

The difficulty is security during transmission and how to store secrets. Someone being able to update a firmware update to exfiltrate your TOTP keys is really bad.

[mateMathieu]

@Avamander Thanks!

Just mentioning that it isn't being actively developed or maintained, AndOTP is probably a better choice.

FreeOTP is "kind of maintained". But certainly not developed since the usage is said to be satisfactory, though it had a UI overall last year, so I trust your advice about AndOTP.

The difficulty is security during transmission and how to store secrets.

Do we need absolutely strong encryption for a one-time transfer of the token over bluetooth? Any encryption stack would do the job.

Someone being able to update a firmware update to exfiltrate your TOTP keys is really bad.

It depends how the update is being carried on, I guess. But here again, I lend you my trust about the technical aspects.

Thank you for pointing to the potential technical difficulties! :)

[Avamander]

Do we need absolutely strong encryption for a one-time transfer of the token over bluetooth? Any encryption stack would do the job.

Depends on if we get secure BLE bonding or not and if it's trustworthy enough for us to use.

It depends how the update is being carried on, I guess. But here again, I lend you my trust about the technical aspects.

Currently unauthenticated and unsigned.

[mateMathieu]

Depends on if we get secure BLE bonding or not and if it's trustworthy enough for us to use.

I am the lucky user of a pebble time steel, and the BLE is used in conjunction to the normal bluetooth connectivity. Hence, it would be interesting to evaluate the use of normal bluetooth for all sensitive data as well as system updates.

Currently unauthenticated and unsigned.

Surely something that will change in the mid-term evolution of the platform.

[Avamander]

I am the lucky user of a pebble time steel, and the BLE is used in conjunction to the normal bluetooth connectivity. Hence, it would be interesting to evaluate the use of normal bluetooth for all sensitive data as well as system updates.

I might've been a bit unclear, sorry. Bluetooth Classic or Bluetooth Low Energy doesn't make much of a difference here. Since Bluetooth 4.1 and Bluetooth Low Energy 4.2 both support relatively the same amount of link-layer encryption. The missing part here is switching to a higher "Security Mode" and to a "Secure Connection" on InfiniTime's side as Bluetooth SIG calls those features. Bluetooth Classic and Bluetooth LE side-by-side (from the middle):
There's also the fact that NimBLE doesn't and probably never will implement Bluetooth Classic.

Second aspect on top of the possible encryption algorithms the protocol(s) offer(s) is how the protocol is designed, there are some concerns that even the best Bluetooth offers could be bad because it deviates from best crypto practices. (Wireless protocol designers in general are notorious with their poor choices and unwillingness to learn from past mistakes, for example WiFi Alliance and its WPA2 and WPA3)

The question in the end is, do we try to maximise what BLE offers and/or do we add something on top of BLE to secure the communications.

Surely something that will change in the mid-term evolution of the platform.

Maybe, but there's currently nobody working on that, I'm sure a PR that implements Nordic's secure "buttonless" high-MTU DFU would be welcome :P

[ObiKeahloa]

FreeOTP

Just mentioning that it isn't being actively developed or maintained, AndOTP is probably a better choice.

Finally, scanning the QR code from your phone and transferring the credentials to the watch would make it very simple.

The difficulty is security during transmission and how to store secrets. Someone being able to update a firmware update to exfiltrate your TOTP keys is really bad.

Maybe AES encrypted updates ?

[GIJack]

This is actually a terrible idea for a smart watch

1. Very much unsecured, compare with android/ios which have considerable work done with security models.
2. There are plenty of TOTP apps that take security a step further, with their own implementations
3. It would be very hard to manage a large amount of keys in a reasonable fashion. Android apps do this currently.
4. It adds nothing over having them on the phone. There are few use cases where you'd need to enter an OTP, but are not in a location where safely retrieving a phone will be an issue.
5. There is limited system resources on the watch

[Avamander]

Very much unsecured, compare with android/ios which have considerable work done with security models.

Very much depends on your threat model. Signed firmware updates from a trusted device will rise the bar significantly.

It adds nothing over having them on the phone.

Depends on the person.

There is limited system resources on the watch.

Not that limited.

[Raupinger]

In principle, I like this idea. I think having more standalone apps is a good thing and that there would be a benefit for people who don't always carry their phones with them. Also depending on the circumstances a wearable might be safer from theft than a phone. But the question remains if it can be done securely. Here are a few reasons I have my doubts about that:

1. Transferring credentials over Bluetooth sounds like a world of potential issues and would require some very robust encryption.
2. Writing security relevant code takes a lot more care than a stopwatch. Just speaking for myself, I wouldn't trust an OTP application written by me.
3. The hardware really isn't well suited for mixing security relevant code with other stuff. The nRF52832 lacks any form of MMU or MPU, which means all other apps can read your OTP applications memory. This isn't that big of an issue right now since Infinitime is a monolithic binary but firstly, that might change and secondly, it might still be possible to do something like cause a buffer overflow in another application via API calls to make it write into the OTP apps memory. The nRF52832 does have AES acceleration but it lacks any kind of secure key storage that could mitigate this kind of stuff.

All those things make me skeptical an OTP app could be build securely with reasonable effort and considering the last point maybe at all.

[afeuerstein]

What's about storing the keys and processing the codes on you phone and sending them to the watch through a secure bluetooth connection when requested?

[denharad]

I'm trying to migrate from my Pebble watch, & found the Authenticator software an important part of my workflow as I have 2-4 sites I need to generate OTP codes for daily. Unlocking an account in this manner takes around a third of the time it would, compared with accessing an app directly on the phone. Granted I don't have a very fast phone, but this lowers login frustration considerably. I would absolutely love to see it implemented within Infinitime http://apps.rebble.io/en_US/application/52f1a4c3c4117252f9000bb8 https://github.com/cpfair/pTOTP

[adocampo]

What's about storing the keys and processing the codes on you phone and sending them to the watch through a secure bluetooth connection when requested?

I think the footprint for an OTP watchapp would be so small it can safely be completely standalone. The companion app should be used only for convenience to enter new tokens through a QR or with keyboard, put a label on it, and reorder them, then sync to the watchapp. Besides, the idea, imo, is to have a fully functional TOTP watchapp, and not depending on the phone for its everyday use. In this way, it will increase security because there would be no need to transfer the tokens wirelessly because the watch can generate them by itself.

[Boteium]

I think we can re-visit this idea now. Security for both transfer & storage are not really that difficult.

Transfer

• If security of bluetooth is not to be trusted. How about letting users type in their base32 key. We now have a proof-of-concept keyboard https://github.com/InfiniTimeOrg/InfiniTime/pull/1466

Storage

• I think simply storing aes encrypted ciphertext is already acceptable. The app then decrypt the seed by a passcode enter by the user via the on screen keyboard. Unlike ascii text, OTP seed in binary form are random enough. If we encrypt the seed in binary form instead of the base32 encoded binary seed, there is no way to brute force the ciphertext because all decryption key are valid and will all yield valid output. On the other hand, encrypted ascii text would be cracked within seconds. And because of the randomness of OTP seed, we can simply use the hash of passcode as key. I don't think we need to use PBKDF.