Security

Our Security Stance

BE Authentic exists to answer a question — is this real? — about physical objects. That mission means our security posture has to be different from a typical web service. We don’t just need to keep our database from being breached; we need to make sure the trust we attest can survive the loss of our own infrastructure.

This page describes the technical foundations of our security architecture, the threat model we design against, and how to report a vulnerability if you find one.

Cryptographic Primitives

We use established, well-reviewed cryptographic algorithms rather than novel constructions. Specifics:

Layer	Algorithm	Purpose
NFC chip authentication	NTAG 424 DNA with CMAC	Each tap produces a hardware-keyed signature over a unique ID and a monotonic counter. The same chip family used in luxury goods and contactless payment.
Server-side event signing	Ed25519	Every verified event is signed by a Vector Normal-controlled key. Public key is published openly.
Transport encryption	TLS 1.2 or higher	All communication between your device, our apps, and our servers.
SDM key storage at rest	AES-256	Sensitive chip credentials encrypted at rest under a dedicated encryption key.
Account password storage	Salted hashing (industry-standard algorithm)	Passwords are never stored in cleartext or reversible form.
Mobile device credential storage	Hardware-backed (Apple Secure Enclave, Android Keystore)	Refresh tokens and cached credentials are stored in hardware-backed key storage on supported devices.
Biometric unlock	On-device only (Face ID, Touch ID, fingerprint)	Biometric data never leaves your device. We never see it, store it, or transmit it.
Analytics IP handling	SHA-256 with per-site salt	Raw IP addresses are never persisted. Per-IP-per-day deduplication is applied to hashed values.

Independent Verifiability

The architectural choice that distinguishes BE Authentic from most authentication platforms is that verification works without our cooperation.

Our Ed25519 public verification key is published at be-authentic.me/wp-json/arcform/v1/provenance/public-key. Anyone with a copy of a signed Provenance Record event can verify it against this key using standard cryptographic libraries. We don’t have to be online, we don’t have to be in business, and we don’t have to be cooperating.

This is what makes BE Authentic durable as long-term provenance. The trust is in the cryptography, not in the company.

Infrastructure Separation

We separate platform-level Vector Normal infrastructure from Licensee-operated infrastructure, particularly around payments and high-sensitivity financial data.

• Vector Normal does not store full payment card numbers, bank account numbers, or analogous high-sensitivity payment credentials.
• Payment processing for Licensee transactions (e.g., Arcform marketplace transactions) is handled by the Licensee’s own PCI-compliant infrastructure or by their payment processor.
• Identity verification (where required) is handled by vetted third-party identity providers, not by Vector Normal directly. We receive pass/fail or limited verified-attribute results.
• The cryptographic verification path — the part that determines whether a tap is real — runs entirely on Vector Normal infrastructure and is not dependent on any Licensee system.

This means a compromise of a Licensee’s payment system, while serious for that Licensee, does not compromise the integrity of BE Authentic Provenance Records.

Access Controls and Operational Security

• Role-based access control on production systems with least-privilege defaults.
• Audit logging of administrative actions, with logs retained according to applicable legal and operational requirements.
• Strict segregation between signing keys and operational data. Signing keys never appear in application logs, database dumps, or other places they might be inadvertently exposed.
• Production environment isolation from development and staging.
• Backups and disaster recovery regularly tested. Backup retention is limited to a commercially reasonable period beyond active deletion.

What We Don’t Collect or Store

Some of the strongest security commitments are about data we don’t have. By architecture:

• No GPS or continuous location data. The NFC chip in a BE Authentic object has no battery and emits no signal on its own. We have no mechanism to track an object’s location between user-initiated taps.
• No ambient scanning data. We do not collect or process passive radio signals, Bluetooth beacons, or other ambient telemetry.
• No biometric data. Face ID, Touch ID, and similar features are used only on-device to unlock cached credentials. The biometric template never leaves your device.
• No raw IP addresses in analytics. Our first-party site analytics hashes IPs (SHA-256 with per-site salt) before any persistence.
• No retroactive movement reconstruction. Our database is structured to answer “was this user present at this verified interaction” — not “where has this user been.” There is no query in our system that produces the latter.
• No third-party tracking pixels or behavioral advertising tags. We do not embed third-party trackers in our applications or web properties.

Data we don’t collect cannot be breached, subpoenaed, or sold.

Threat Model

We design and review against the following threat classes, in roughly the order we prioritize them:

1. Forgery of provenance. Someone attempts to fabricate a Provenance Record, manipulate verification events, or impersonate an authenticated object. The hardware-backed chip signature, the monotonic counter, and the server signature together make this computationally infeasible.
2. Replay of verification packets. Someone captures a real tap packet and tries to replay it later. The monotonic counter check at the verification server rejects any packet whose counter is not strictly greater than the previously recorded value.
3. Compromise of Vector Normal infrastructure. An attacker gains access to our servers. Because cryptographic verification of existing events depends on the public key (not on server availability), historical records remain verifiable. Forward security depends on operational controls described above.
4. Compromise of an account credential. An attacker gets a user’s password or session token. Hardware-backed credential storage on mobile, salted password hashing, and rate-limited authentication endpoints raise the cost of this attack. Account compromise is detectable through unusual interaction patterns and triggers temporary suspension while we investigate.
5. Privacy leakage through metadata. An attacker tries to reconstruct sensitive information from BE Authentic data they have access to. Our schema is intentionally minimal; we don’t store or process the kind of metadata that would enable this kind of attack.
6. Algorithmic obsolescence. Future cryptanalytic advances or quantum computing weaken current algorithms. Our architecture is designed to support algorithm migration while preserving the verifiability of records signed under prior algorithms.

Threat classes we explicitly do not attempt to defend against include nation-state-level supply-chain compromise of physical chip suppliers, and an attacker who has physical possession of the object, an unlocked authenticated mobile device, and the user’s credentials simultaneously. In that scenario, no authentication platform can save you.

Responsible Disclosure

If you believe you’ve found a security vulnerability in BE Authentic, we want to know. We commit to:

• Acknowledging your report within five business days;
• Investigating in good faith;
• Keeping you informed of our progress at a reasonable cadence;
• Not pursuing legal action against researchers acting in good faith under this policy;
• Crediting you, with your permission, when we publish information about a fix.

Please report security issues to security@be-authentic.me. Encrypted communication is welcome; reach out via security@ to coordinate PGP.

We ask in turn that you give us a reasonable period (typically 90 days, longer for complex issues) to address the vulnerability before public disclosure, and that you avoid accessing data beyond what is necessary to demonstrate the issue.

What’s Inspectable Today

If you want to verify our claims yourself, the following are publicly inspectable right now:

• Our Ed25519 verification key
• The Licensee registry
• The AI engine registry
• The Privacy Policy and Terms of Service

Over time, we plan to publish additional portions of the protocol specification and an external audit. Transparency is part of the product.