Security and privacy

Trust model

• Every signed-in user can read and write the whole inventory. Version 1 has no permissions per record or entity type. A server that needs them (for example read-only users) can reject pushes with 403 and forbidden, but clients do not expect it and will keep the changes locally.
• Devices are trusted with their data. A device holds a full copy of the inventory, including personal data of recipients and signatures. Losing a device means losing that copy; device encryption and a passcode are the protection.
• The server is trusted with relaying. It sees all records and attachments in plain form. End-to-end encryption is not part of version 1.
• The licence is the only signed data. Records are not signed; a user who can push can write any version with any stamp.

Transport

• Servers reachable from the internet MUST use HTTPS (TLS 1.2 or later) with a valid certificate. Clients MUST NOT disable certificate validation.
• Plain HTTP is acceptable only in a trusted local network; see Transport basics.
• Servers SHOULD send Strict-Transport-Security on HTTPS.

Credentials and tokens

• Passwords are sent only to POST /lve/v1/auth/token and are stored on the server only as a slow hash (the reference server uses Laravel's default, bcrypt). Clients do not store passwords.
• Tokens are bearer secrets. Clients store them in the platform's secure storage (the iOS keychain in the reference app). Servers store only a hash of each token (Laravel Sanctum stores SHA-256).
• Tokens do not expire on their own. Administrators revoke the tokens of lost devices; signing in again from the same device id replaces the old token.
• Sign-in endpoints MUST be rate-limited. The reference server allows 10 attempts per minute and client address across both sign-in endpoints.

Pairing codes

• A code signs a device in without a password, so it is as sensitive as a password for its lifetime. Show it only to the person who should use it; the QR code contains it in clear text.
• Codes are single use, expire (24 hours by default on the reference server), and are compared only through a keyed hash (HMAC-SHA256 with the application key). A database dump does not reveal valid codes.
• The reference server's codes have about 39 bits of entropy. Together with the rate limit this is enough for a code that lives for hours, not for long-lived codes.
• The server in a pairing link decides where the device sends its data. Clients SHOULD show the server address before connecting, so that a forged QR code cannot redirect a device unnoticed.

Attachments

• Attachments are addressed by SHA-256 and verified on upload and on download, so a client cannot overwrite another file and a corrupted download is discarded.
• Any signed-in user can download any attachment whose hash it knows. Hashes appear only in records, which the same users can read anyway.
• Servers limit the upload size (20 MiB) and stream uploads to disk; they do not decode or render attachments. Clients that render images and PDFs from other devices should use the platform's sandboxed decoders.
• The reference server serves attachments with the stored content type and Cache-Control: private; servers SHOULD also send X-Content-Type-Options: nosniff and SHOULD NOT serve attachments from the same origin as an administrative web interface.

Personal data

Records contain personal data:

Where	Data
recipient	names, addresses, phone numbers, email addresses, personnel numbers, departments
delivery_note, loan	copies of the above at the time of issue; names of signers
movement, documents	booked_by, issued_by, received_by: names of staff
attachments	handwritten signatures, photos (which may show people or places)
company_profile	the company's details, bank account

• Operators of a server are responsible for this data under the applicable data protection law (for example the GDPR). The protocol stores no data beyond what users enter, plus device names and models at sign-in.
• Because records are never physically deleted (tombstones keep the last stamp, the change log keeps every version), erasing a person's data requires administrative work on the server: overwrite the affected records with new versions that remove the data (a server-side write wins on every device), and remove the old versions from the change log and the attachments that are no longer referenced. Devices keep their copy until they sync; signed documents (delivery notes, loans) may have to be kept for legal reasons anyway.
• Clients SHOULD protect their local store with the platform's file protection. The reference app stores attachments with "complete until first user authentication" protection.

Server hardening checklist

• HTTPS only, current TLS configuration.
• Rate limits on sign-in; optionally a general limit per token.
• Request body limit of at least 20 MiB on the attachment route, small limits elsewhere.
• Logs without request bodies and tokens.
• Database and attachment storage backed up and encrypted at rest.
• The application key (which keys the pairing code hashes) kept secret and stable.
• Administrative interfaces behind separate authentication.