Skip to content

v0.5.2 — Release de sécurité

Choose a tag to compare

@gitubpatrice gitubpatrice released this 31 Jul 18:37
· 96 commits to main since this release

🇫🇷 Release de sécurité

Trois défauts trouvés par audit, dont un critique présent depuis le tout premier commit.

La base n'était pas réellement protégée

La vraie passphrase — 32 octets aléatoires, scellés sous l'AndroidKeyStore — était bien générée et bien stockée, mais jamais utilisée. Le tableau qui la portait était effacé de la mémoire juste après la construction de la base ; or Room n'ouvre réellement le fichier qu'à la première requête. Quand SQLCipher réclamait enfin la clé, il ne recevait plus que des zéros.

Conséquence : agendatech.db était déchiffrable par quiconque parvenait à l'extraire de l'appareil, sans avoir à toucher au coffre matériel.

Corrigé — et les bases existantes sont rechiffrées automatiquement au premier lancement, sans perte : l'agenda est copié de côté avant l'opération et remis en place si quoi que ce soit échoue. L'opération est jouée une seule fois, en arrière-plan.

Le compteur anti-force-brute du code PIN se réinitialisait trop facilement

Il ne vivait qu'en mémoire : fermer l'application de force — quelques appuis dans les réglages, aucun outil, aucun privilège — remettait le compteur à zéro et redonnait cinq essais. L'escalade des délais ne servait donc à rien face à quelqu'un de patient. Le compteur est désormais conservé d'un lancement à l'autre ; le plafond d'une minute est inchangé.

L'application se figeait pendant la sauvegarde et la restauration

Le calcul cryptographique qui protège un fichier .atbak (volontairement lent, c'est ce qui le rend résistant) tournait sur le fil de l'interface : gel d'environ une seconde à chaque export, et bien plus long face à un fichier hostile, au point de pouvoir faire tuer l'application par Android. Passé en arrière-plan.

Aussi

Démarrage plus fluide : la base était ouverte sur le fil de l'interface au lancement.


🇬🇧 Security release

Three flaws found by audit, including a critical one present since the very first commit.

The database was not actually protected

The real passphrase — 32 random bytes, sealed under the AndroidKeyStore — was generated and stored correctly, but never used. The array holding it was wiped from memory right after the database was built; but Room only opens the file on the first query. By the time SQLCipher finally asked for the key, all it got was zeros.

The upshot: agendatech.db could be decrypted by anyone able to extract it from the device, without ever touching the hardware vault.

Fixed — and existing databases are re-encrypted automatically on first launch, with no data loss: the agenda is copied aside beforehand and put back if anything fails. It runs once, in the background.

The PIN brute-force counter reset far too easily

It lived only in memory: force-stopping the app — a few taps in Settings, no tools, no privileges — reset the counter and handed back five fresh attempts. The escalating delays were therefore useless against a patient attacker. The counter now persists across launches; the one-minute ceiling is unchanged.

The app froze during backup and restore

The cryptographic work protecting an .atbak file (deliberately slow — that is what makes it resistant) ran on the UI thread: roughly a one-second freeze on every export, and far longer against a hostile file, to the point of being killed by Android. Moved to the background.

Also

Smoother startup: the database was being opened on the UI thread at launch.


Certificat de signature (inchangé) : 538bff8ab3162017038d031909fd4e06159f30a3371867f9e1d1bc146c9a1d04