0

I recently got a Galaxy Watch and to get acquainted with developing apps for it I'm writing a simple two factor authenticator to generate TOTP codes from entered secrets using the Google Authenticator algorithm. I found this SQLite example for encrypting information and storing it at the Tizen Developer site https://developer.tizen.org/development/guides/native-application/data-storage-and-management/sqlite-database-engine and I've used it to store entered secrets and load them when the application reopens. (I'm not currently using this on actual 2FA secrets from my real accounts, just on test data.)

The example page says:

While operating with real data, make sure that you fulfill all security requirements. This guide demonstrates how to use the library APIs on Tizen, but does not show how to perform fully secure encryption.

Supposing I want to use the application with real secrets in the future:

  1. Is it common and/or good practice for 2FA apps to encrypt 2FA secrets on the device? It seems to me that, using this example at least, the database could be brute forced by an attacker if a copy were obtained, so the secrets should be assumed compromised if the device were lost or stolen. Encryption would then serve primarily to buy a little extra time to revoke the stored 2FA secrets and change them. Is this accurate or am I misunderstanding the example?
  2. If this example is a reasonable approach to store 2FA secrets, what changes to the example would be necessary to "perform fully secure encryption"? I have replaced DummyPassword in the example with a password entered every time the application starts (i.e. the password is not stored in the code or on the device anywhere), and I assume the RAND_bytes calls should be replaced, ideally with an algorithm that doesn't require manual sanitation by replacing quotes and apostrophes with 'a' and 'b'.
manfromscene24
  • 1
  • 1
  • I'm not familiar with the Galaxy Watch security model, so - just to confirm - apps on the device cannot read the data of other apps, but the device itself doesn't normally require authenticationof any sort (PIN or whatever) when used, right? So your main threat actor is somebody who steals a watch with secrets stored in one of its apps, and you're trying to protect those secrets on a platform that assumes any user of the device is legit (and therefore the app needs to implement authentication itself); is that correct? – CBHacking Jan 21 '19 at 19:54
  • Yes that is my understanding, although I'm very new to the platform and still reading the documentation. A screen lock can be added, although it seems it does not encrypt or otherwise protect the internal storage so I would be concerned someone stealing the watch could still access the secrets whether the screen lock is present or not. – manfromscene24 Jan 21 '19 at 23:09

0 Answers0