5 related insights
Use this topic page to move quickly through the most relevant Attomus thinking without losing the wider context across the full insights section.
Insights Topic
Signet
Browse Attomus insight related to signet, with a focus on programme delivery, operational judgement, and professional execution in demanding environments.
The Authentication Model Contradiction Nobody Talks About
Authenticator apps look simple. They generate six-digit codes. The cryptography is forty years old. The protocol is an IETF RFC from 2011. You could probably implement the core algorithm in a lunch break. The genuinely hard part isn’t the TOTP maths. It’s a design tension baked into the product category itself, one that every authenticator app has to resolve, that most resolve quietly and without documentation, and that the industry has somehow decided not to discuss openly.
Read articleWhat Android's Keystore Actually Does with AES Keys (and What It Doesn't)
There is a question that comes up constantly in Android security engineering, usually phrased something along the lines of: “how do I prove to my server that this AES key is hardware-backed?” The common answers to this question are often wrong in that they make you think you have a guarantee that you do not have. The short answer is: you cannot prove an AES key’s hardware provenance to a server directly. The certificate chain mechanism that makes remote attestation possible for asymmetric keys does not exist for symmetric keys. If you are building a system that depends upon being able to remotely attest an AES key’s provenance, you need to redesign the system, not find a better API call.
Read articleThe Wrong Way to Market a Security Product, and What to Do Instead
“Military-grade encryption.” “Zero-knowledge architecture.” “Bank-level security.” “Secure enclave protection.” These phrases appear all over the App Store listings for security products, and most of them are meaningless, misleading, or too vague to be useful. The damage they do reaches well beyond the individual product that deploys them. The argument here is not that the phrases are dishonest, though several are. It is that they are structurally harmful to the security industry, because they train buyers to accept claims instead of demanding evidence. Once buyers have been trained that way, every security product – including the ones with real technical substance behind their claims – has to compete in a market where marketing language is weighed on the same scale as engineering.
Read articleThreat Modelling a Product You Believe In
Threat modelling has a reputation problem. Ask a developer what a threat model is and you tend to get one of two answers. The first: an architectural diagram with threat labels, produced during design and never looked at again. The second: the section of a compliance document everyone writes carefully and nobody reads, including the people who wrote it. Both of those exist. Neither is the version that changes a design. The useful version is different in character from either, and the difference is not methodological. It is about what the process forces you to sit with. Threat modelling gets uncomfortable exactly when you are modelling a product you designed, built, and believe in. That is the version to write about, because it is the one most developers avoid.
Read articleWhy We Chose a 28-Byte Backup Header
The backup format for an authenticator app looks like a solved problem. Encrypt the secrets with a passphrase, write the ciphertext to a file, done. It is not done. The naive version fails silently in several distinct ways, and the worst of them leaves a user holding a file that will never decrypt again, reporting an error that blames their passphrase for something else entirely. The 28-byte header we settled on came out of working through those failures one at a time. The same reasoning applies to any format that combines key derivation with authenticated encryption.
Read article