Security
Data security and encrypted backup
“Your data is encrypted” is what every billing app claims. Below are the actual algorithms, key lengths and iteration counts KVN Billing uses — specific enough that your accountant or IT person can look them up and check.
01 — Backups
A backup is the whole business in one file.
- Cipher
- AES-256 in GCM mode, 128-bit authentication tag. AES-256 is the standard used by banks and governments worldwide. GCM authenticates as well as encrypts, so a backup altered by even one byte refuses to restore rather than loading wrong figures silently. For a ledger that distinction matters more than the encryption itself.
- Key derivation
- PBKDF2 with HMAC-SHA256, 120,000 iterations, 256-bit key. The iterations are the point: they make each guess of your password cost real computing time, so trying passwords in bulk becomes impractical instead of instant. Your password itself is never stored — not in the app, not in the file, not on our server.
- Uniqueness
- A fresh random 16-byte salt and 12-byte IV per backup. Two backups of identical data produce completely different files, so nothing can be learned by comparing them. Reusing an IV with GCM is catastrophic, so one is generated per file and never derived or reused.
- Without a password
- Sealed with a key generated inside the Android Keystore. On most phones sold since Android 9 that key lives in secure hardware and cannot be extracted, even from a rooted device. That backup is safe where it sits but restores only on that handset — set a password if you need to move to a new phone.
- What is inside
- The complete database plus your logo and signature, so a restore onto a replacement phone brings your letterhead back with your ledger. The archive is an ordinary ZIP, deliberately: a backup is the last thing that should depend on our software still existing to be opened.
- In the cloud
- The file is encrypted before it leaves the phone, so the server stores ciphertext. We cannot read your books, and neither can anyone who obtains a copy from the server.
The threat we design for
A phone that is lost, sold or stolen.
That is the realistic risk to a business, not a determined attacker with your handset unlocked in their hand. Everything at rest is encrypted so that a copy of the storage is useless to whoever ends up with it.
02 — On the phone
Sign-in token sealed
A bearer token is enough to act as you until it expires, so it is wrapped with a Keystore key rather than written into settings in the clear. Copying the app data folder off a phone yields ciphertext.
Screenshots blocked
Throughout the app, with no setting to turn it back on. Screen recording and the recent-apps preview are covered too.
Fingerprint on open
Enabled by default once a company exists. Nobody who picks up an unlocked phone gets straight into your books.
Pinned transport
Sync speaks only to our server over TLS with the public key pinned, so an intercepting proxy on a shared network cannot read or alter it.
Separate keys per purpose
Backups and settings use different Keystore keys, so compromising one path cannot unlock another.
Nothing sensitive logged
Release builds are minified and stripped, and no token, password or customer record is written to the device log.
Stated plainly
What this cannot do
A forgotten backup password cannot be recovered or reset by anyone, including us. That is precisely why the encryption is worth anything — a password we could reset is a password an attacker could ask us to reset. Write it down somewhere safe.
Encryption protects data at rest. It does not defend an unlocked phone with the app already open, because at that point the app is decrypting for whoever is holding it, by design.
A page that lists only strengths is marketing. These are the real limits, and knowing them is what lets you plan around them.
Start billing today
Get KVN Billing & Accounting App
We set up your company, GSTIN and invoice numbering before you start, so your very first GST invoice is correct.