Security

Security Architecture

ByteAuth is built on Bitcoin’s battle-tested cryptographic primitives. This page details our security architecture, cryptographic choices, and best practices for implementation.

Why Bitcoin Cryptography?

We deliberately chose Bitcoin’s cryptographic stack because it’s the most adversarially tested system in the world:

The Numbers

$1+ trillion in value secured by secp256k1
15+ years of continuous operation since 2009
Zero cryptographic failures in Bitcoin’s history
Millions of nodes validating cryptographic proofs daily

The Primitives

Component	Standard	Description
Elliptic Curve	secp256k1	256-bit curve used by Bitcoin
Signature Algorithm	ECDSA	Elliptic Curve Digital Signature Algorithm
Hash Function	SHA-256	Secure Hash Algorithm, 256-bit
Key Derivation	BIP-32/39	Hierarchical Deterministic Wallets

Cryptographic Deep Dive

Elliptic Curve: secp256k1

ByteAuth uses the same elliptic curve as Bitcoin:

y² = x³ + 7 (mod p)

Where:

p = 2²⁵⁶ - 2³² - 977 (a 256-bit prime)
Generator point G is standardized
Order n ≈ 2²⁵⁶

Why secp256k1?

Faster signature verification than NIST curves
No suspicious “magic numbers” (unlike P-256)
Extensively audited by the cryptocurrency community
Standardized parameters prevent backdoors

Digital Signatures: ECDSA

The Elliptic Curve Digital Signature Algorithm provides:

Authentication — Proves the signer knows the private key
Non-repudiation — Signer cannot deny creating the signature
Integrity — Any message modification invalidates the signature

Signature Process:

1. Hash the message: h = SHA256(message)
2. Generate random k (nonce)
3. Calculate r = (k × G).x mod n
4. Calculate s = k⁻¹(h + r × privateKey) mod n
5. Signature = (r, s)

Hash Function: SHA-256

All messages are hashed with SHA-256 before signing:

256-bit output — Collision-resistant up to 2¹²⁸ operations
Preimage resistant — Cannot reverse hash to find input
Second preimage resistant — Cannot find different input with same hash
NIST standardized — Published, audited, trusted

Key Derivation: BIP-32/39

ByteVault derives domain-specific keys using Bitcoin standards:

Master Seed (256 bits)
    ↓
Master Key (BIP-32)
    ↓
Purpose Key (m/44')
    ↓
Coin Type Key (m/44'/0')
    ↓
Account Key (m/44'/0'/0')
    ↓
Domain Key (m/44'/0'/0'/domain_hash)

Benefits:

Single backup (seed phrase) recovers all keys
Unique key pair per domain (privacy)
Compromising one domain doesn’t affect others
Deterministic — same seed always produces same keys

Threat Model

What ByteAuth Protects Against

Credential Theft

Private keys never leave the device. There’s nothing to steal from servers.

Phishing Attacks

Users verify the domain in ByteVault before signing. Signatures are domain-bound.

Database Breaches

Only public keys are stored. They’re called “public” for a reason.

Replay Attacks

Challenges expire in 30 seconds and include unique nonces.

Man-in-the-Middle

Signatures include the target domain. Intercepted signatures can’t be reused.

Brute Force

256-bit keys have 2²⁵⁶ possibilities. The sun will burn out first.

What ByteAuth Doesn’t Protect Against

Device compromise — If an attacker has full control of the user’s phone
Coerced authentication — If a user is physically forced to authenticate
Lost seed phrase — If the user loses their backup and device
Social engineering — Tricking users into authenticating to malicious sites

Comparison with Other Auth Methods

vs. Passwords

Attack Vector	Passwords	ByteAuth
Credential stuffing	Vulnerable	Immune
Phishing	Highly vulnerable	Resistant
Database breach	Catastrophic	No impact
Brute force	Possible	Impossible
Rainbow tables	Possible	N/A
Keyloggers	Vulnerable	Resistant

vs. WebAuthn/Passkeys

Aspect	WebAuthn	ByteAuth
Key custody	Platform (Apple/Google/Microsoft)	User
Cross-device	Requires same ecosystem	Any device via QR
Recovery	Platform-dependent	Seed phrase
Bitcoin integration	None	Native
Biometric binding	Platform-enforced	App-enforced

WebAuthn’s limitations:

Keys tied to platform accounts (not self-sovereign)
Cross-device auth requires ecosystem buy-in
No standard recovery mechanism
Can’t integrate with Bitcoin/Lightning

vs. LNURL-auth

Aspect	LNURL-auth	ByteAuth
Wallet requirement	Lightning wallet	ByteVault
Network dependency	Lightning Network	None
Biometric requirement	Wallet-dependent	Always required
Liveness detection	None	Built-in
Corporate adoption	Limited	Growing

LNURL-auth’s limitations:

Requires functional Lightning wallet
Network connectivity for signing
No biometric enforcement standard
Limited enterprise tooling

Biometric Security

ByteVault requires biometric authentication before signing:

Face ID / Touch ID (iOS)

Uses Secure Enclave for key protection
Biometric data never leaves device
Hardware-backed attestation

Biometric API (Android)

Keys protected by TEE (Trusted Execution Environment)
BiometricPrompt API enforces strong auth
Hardware security module on supported devices

Liveness Detection

ByteVault includes passive liveness detection to prevent:

Photo attacks
Video replay attacks
3D mask attacks
Screen capture attacks

Implementation Best Practices

Server-Side

// ALWAYS verify signatures cryptographically
const isValid = verifySignature(publicKey, signature, challenge);
if (!isValid) {
  throw new Error('Invalid signature');
}

// ALWAYS check timestamp freshness
const age = Date.now() / 1000 - payload.timestamp;
if (age > 30) {
  throw new Error('Challenge expired');
}

// ALWAYS validate challenge format
if (!challenge.startsWith('byteauth:')) {
  throw new Error('Invalid challenge format');
}

// ALWAYS use HTTPS for webhooks
// ALWAYS verify webhook signatures
// ALWAYS rate limit authentication attempts

Client-Side

// DO refresh QR codes every 30 seconds
setInterval(refreshQR, 30000);

// DO poll for status at reasonable intervals
setInterval(checkStatus, 5000);

// DON'T store session IDs in localStorage (use httpOnly cookies)
// DON'T implement signature verification client-side
// DON'T display sensitive data in QR codes

Infrastructure

Use TLS 1.3 for all communications
Implement rate limiting on all auth endpoints
Log all authentication events for audit trails
Monitor for anomalies (impossible travel, unusual patterns)
Rotate webhook secrets periodically

Security Checklist

Before going to production:

Incident Response

If you suspect a security incident:

Don’t panic — ByteAuth’s design limits blast radius
Rotate webhook secrets immediately
Review authentication logs for anomalies
Contact security@bytefederal.com for support
Notify affected users if appropriate

Security Contact

Report security vulnerabilities responsibly:

Email: security@bytefederal.com
PGP Key: [Available on our website]
Bug Bounty: [Contact for details]