Security
Every credential is a
mathematical proof.
AcadCert signs every document with Ed25519, the same elliptic-curve algorithm used by OpenSSH, Signal, and modern TLS. Verification is not a database lookup. It is cryptographic certainty: the signature either matches the document or it does not.
Contents
Guarantees
Three things every credential proves
The credential came from who it claims.
Every document is signed with the issuing institution's private key. An employer can verify the signature against the institution's public key, no central authority, no black-box trust in AcadCert required.
A single changed byte breaks the signature.
The document is hashed with BLAKE3 before signing. If anything in the file changes after issuance, including metadata or embedded data: the signature becomes invalid. There is no threshold or tolerance.
The issuer cannot deny having signed it.
The signature is mathematically bound to the institution's key. Combined with an independent timestamp proof under RFC 3161, the issuance event is permanent and irrefutable, not contingent on AcadCert's word.
Verification model
Up to six independent checks
Anyone can verify any AcadCert credential at verify.acadcert.com with no login, no fee, and no student involvement. Verification runs up to six checks and returns a deterministic result. There is no partial pass.
The Ed25519 signature matches the document content against the institution's public key. Any modification to the file since signing causes this check to fail.
The institution had an active, valid signing key at the time of issuance and the issuer was authorized to sign on its behalf.
The credential has not been revoked or superseded. Revocations are recorded immediately and reflected on all subsequent verification requests.
The credential metadata (recipient, issuing institution, document type, and issuance date) matches the signed payload exactly. Any inconsistency causes this check to fail.
Runs only on credentials issued with an expiry date. The credential is within its validity window; one past its expiry returns EXPIRED, even though its signature remains cryptographically intact.
An independent RFC 3161 authority recorded the signing timestamp. This prevents backdating (claiming a credential was issued earlier than it was) or future-dating.
Cryptography
Ed25519 signing model
Ed25519 uses Curve25519, designed for high security and correct implementation. Signatures are 64 bytes. The construction is deterministic, no random nonce required during signing: which eliminates an entire class of attack that has compromised RSA and ECDSA deployments in practice.
Security strength: ~128 bits, equivalent to RSA-3072 under NIST guidelines. Resistant to timing side-channels by construction.
The choice of Ed25519 over RSA or ECDSA is deliberate. ECDSA signing requires a random nonce per operation. If that nonce is weak, reused, or biased, the private key can be recovered algebraically from two signatures. This is not theoretical: it is the exact mechanism behind the Sony PlayStation 3 key extraction and a class of Bitcoin wallet attacks. Ed25519 derives its nonce deterministically from the private key and message, making nonce reuse structurally impossible. RSA under PKCS#1 v1.5 carries its own history of padding oracle attacks; Ed25519 has no equivalent padding surface.
Beyond safety, Ed25519 is faster: verification throughput is significantly higher than RSA-2048, and key and signature sizes are a fraction of their RSA equivalents (32-byte public key, 64-byte signature versus 256-byte RSA-2048 key and signature). This matters at scale and makes the algorithm practical for verifiers with constrained environments.
Why BLAKE3 for hashing
BLAKE3 is the hashing algorithm applied to each document before signing. SHA-2 (SHA-256, SHA-512) is structurally vulnerable to length-extension attacks: an attacker who knows H(m) can compute H(m ∥ suffix) without knowing m. BLAKE3 is not susceptible to this; its tree-based Merkle construction makes length-extension attacks impossible by design. BLAKE3 also parallelises across CPU cores and SIMD lanes, making it substantially faster than SHA-2 on modern hardware without sacrificing the security margin. It carries none of the legacy design constraints inherited from MD4 that are present in the SHA-1 and SHA-2 lineage. The result is a hash function that is simultaneously faster, safer against structural attacks, and unencumbered by historical baggage.
What happens when a credential is issued
- 1Issuer uploads a PDF and selects a recipient.
- 2System validates the issuer's authority and the file integrity.
- 3The document is hashed with BLAKE3. The hash, not the private key, is sent to AcadCert Vault for signing.
- 4AcadCert Vault signs the hash with Ed25519 and returns the signature. The private key never leaves the Vault or enters the application's memory.
- 5Signature, hash, and metadata are stored by the application.
- 6An independent RFC 3161 timestamp authority records the signing time.
Key management
Per-institution key pairs
Each institution holds its own Ed25519 keypair, custodied in AcadCert Vault. Private keys never leave Vault custody unencrypted, and never enter the main application’s process at all.
- ✓Private keys encrypted at rest with AES-256-GCM and a unique salt per institution, held exclusively within AcadCert Vault.
- ✓Decrypted only inside the Vault during signing, never in the main application's memory, and never written to disk in plaintext.
- ✓Vault master-key custody uses Shamir secret sharing: no single share is sufficient to reconstruct it, and the Vault is reachable only over mutual TLS under strict network-level access controls.
- ✓Key rotation supported: old public keys are preserved so historical credentials remain valid after rotation.
- ✓Keys are never exposed to issuers, students, or administrators. No user ever sees a private key.
Authentication
No passwords to steal
AcadCert uses passwordless authentication. Login requires a one-time code sent to your registered email, expiring in minutes. There is no password database, no password reset flow, and no credential stuffing surface.
- ✓Sessions use httpOnly cookies, inaccessible to JavaScript and unreadable by XSS.
- ✓CSRF tokens protect all state-changing API requests.
- ✓Sessions are verified server-side on every authenticated request, not just at login.
- ✓Session expiry is enforced server-side with an 8-hour limit.
- ✓Rate limiting on OTP requests prevents enumeration and brute-force attempts.
Infrastructure
Transport and perimeter
The frontend is served via Cloudflare Pages with edge caching, DDoS protection, and bot management. All traffic is HTTPS-only.
- ✓TLS 1.2+ enforced. Older protocol versions are rejected at the edge.
- ✓HSTS with 1-year max-age and preload submission, preventing protocol downgrade even on first contact.
- ✓Content-Security-Policy headers restrict script, frame, and resource sources.
- ✓X-Frame-Options: DENY prevents clickjacking. X-Content-Type-Options: nosniff prevents MIME sniffing.
- ✓Authenticated routes are marked Cache-Control: no-store and X-Robots-Tag: noindex.
- ✓Cross-Origin headers (COEP, COOP, CORP) isolate the origin from side-channel attacks.
Threat model
Known attack scenarios
Compromised issuer account
A compromised account cannot generate valid credentials. Signing keys are server-side only. Issuers never see them and cannot invoke signing outside the controlled upload flow. The account's OTP logs would also reveal the anomaly immediately.
Database breach
Private keys are stored encrypted with AES-256-GCM using a per-institution salt. Even full database access yields nothing usable: the keys required to decrypt them live in AcadCert Vault, a dedicated Key Management Service reachable only over mutual TLS from the application, never the database.
Document tampering
Any modification to a signed PDF, any single byte: breaks the Ed25519 signature. Verification detects this instantly and returns TAMPERED status. There is no way to modify a signed document and maintain a valid signature without the private key.
Insider misuse
Every credential operation is logged with the issuer's identity, IP address, timestamp, and document details. Logs are append-only and tamper-evident. Anomalous patterns are surfaced in the security events log.
Weak cryptographic secrets
AcadCert Vault enforces key strength at custody time and refuses to hold material that doesn't meet it. There is no fallback to weaker algorithms. Ed25519 and AES-256-GCM are non-negotiable and cannot be downgraded through configuration.
Stolen credential file
A stolen credential file alone is useless for forgery. The signature cannot be re-signed without the private key. Recipients can run the full layered verification check at any time to confirm current legitimacy, including revocation status.
Session hijacking
Sessions use httpOnly cookies, inaccessible to JavaScript. CSRF tokens protect all state-changing requests. Sessions expire after a fixed window and are verified server-side on each authenticated request.
Network interception
All traffic is served over TLS 1.2+. HSTS headers enforce HTTPS with long max-age and preloading. HSTS preload submission prevents protocol downgrade attacks even on first contact.
Malicious document upload
Uploaded files are validated for structure and MIME type server-side before any signing operation. The signing pipeline does not execute document content. Structural anomalies cause rejection before the key is touched.
Account enumeration
The OTP flow returns identical responses whether or not an email address is registered. Response timing is normalized. This prevents attackers from learning which email addresses have accounts.
Replay attack on verification
Verification is stateless and read-only. Each verification request is evaluated against the current credential state. There is no token or session that could be replayed to obtain a different result.
Upload security
Input validation and upload security
The document ingestion pipeline applies multiple independent validation layers before any cryptographic operation is attempted. Validation is server-side and cannot be bypassed by the client.
- ✓File type validation uses server-side MIME inspection independent of the file extension declared by the uploader. Extension spoofing is detected and rejected.
- ✓File size limits are enforced at the API layer before any processing begins. Oversized payloads are rejected before the body is parsed.
- ✓PDF structure validation: malformed or structurally invalid PDFs are rejected before signing. The platform does not execute or render document content.
- ✓Uploaded files are processed in memory. No temporary files are written to the working directory during the pipeline.
- ✓File content is never interpreted as executable code. The signing pipeline treats documents as opaque byte sequences to be hashed, not as instructions to be evaluated.
Audit
Audit log integrity
Every write operation in the system produces a permanent, immutable audit record. The log is the authoritative history of all actions taken within an institution.
- ✓Every write operation (issue, revoke, supersede, content erasure, user management, key operations) produces an immutable audit record at the moment it occurs.
- ✓Records include: actor identity, IP address, timestamp (monotonic clock), operation type, affected resource ID, and outcome.
- ✓The audit log is append-only. Existing records cannot be modified or deleted through any application interface.
- ✓Anomalous sequences (mass revocations, unusual login patterns) are surfaced in the administrator security events panel for review.
- ✓Content erasure (crypto-shredding) destroys a stored document file permanently, but never the record of the action: who erased, what, and when remain in the chain, and the credential stays verifiable against its retained hash and signature.
Revocation
Revocation model
Credential revocation is designed for correctness under adversarial conditions: no caching ambiguity, no grace windows, no reinstatement through the application.
- ✓Revocation is immediate and globally consistent. A revoked credential fails verification on the next request after revocation. There is no grace window or cache lag.
- ✓Revocations are permanent and irreversible through the application. Reinstatement requires re-issuance of a new credential.
- ✓The revocation record stores the reason, revoking party identity, and timestamp, creating a complete chain of custody.
- ✓Public verification reflects revocation status without exposing the revocation reason to third-party verifiers. The verifier learns that a credential is invalid, not why.
Compliance posture
Built to recognised control practices
AcadCert is engineered to the control practices behind frameworks like ISO 27001 and SOC 2, and to the data-protection principles of the PDPA and GDPR.
To be precise: these are the practices we build to, not certifications we hold. AcadCert has not undergone a SOC 2, ISO 27001, HIPAA, or GDPR audit, and makes no claim to those certifications. What follows is what is actually implemented.
Encryption at rest
Stored document contents are encrypted with AES-256-GCM under a per-document key; signing keys are held separately in AcadCert Vault.
Encryption in transit
All traffic is served over TLS 1.2+ with HSTS enforced.
Append-only audit logging
Security-relevant actions are recorded in hash-chained, tamper-evident logs that cannot be selectively deleted or switched off.
Data export
Account holders can export their own data, their profile, credentials, and recent activity, on demand.
Cryptographic erasure
An institution can crypto-shred a stored document: the file becomes permanently unrecoverable, while the credential record stays verifiable.
Least-privilege access
Role-based access control, CSRF protection, rate limiting, and signing keys that exist only within AcadCert Vault, never the application itself.
See our Privacy Policy for data handling, retention, and your rights.
Disclosure
Responsible disclosure
Found a vulnerability? Email security@acadcert.com. We acknowledge within 24 hours and aim to resolve critical issues within 72 hours. Please do not disclose publicly until we have had the opportunity to address it. We are grateful for responsible reports and will credit researchers who assist us.
Credits
We are grateful to everyone listed here.