Cryptography Review
Review of cryptographic architecture and implementation, from key generation, provisioning and storage to signing, device identity, secure boot, firmware updates and protocol security.
Where implementation determines the security of the trust model, we follow it into firmware, source code or protocol behavior.
Cryptography is a system, not an algorithm.
Strong primitives do not compensate for weak key handling, broken trust assumptions or incorrect implementation. A secure design depends on where keys originate, where they live, who can use them and how trust changes over the product lifecycle.
The relevant question is not “Are we using a strong algorithm?” but: Does the full trust and key lifecycle remain secure in the actual product?
What we review
Cryptographic architecture
Algorithms, protocols, trust anchors, key hierarchy, security assumptions and where cryptographic decisions are made.
Key lifecycle
Generation, entropy sources, provisioning, distribution, storage, access, rotation, revocation and retirement.
Signing & verification
Firmware signing, update authorization, secure boot, certificates, trust-anchor handling and signature-validation logic.
Device identity
Per-device credentials, PKI, manufacturing provisioning, cloning resistance, authentication, backend trust and revocation for offline fleets.
Protocol cryptography
Handshake design, authentication, encryption, nonce handling, replay protection, session establishment and key derivation.
Implementation
Cryptographic APIs, randomness, secret handling, comparison logic, parser behavior and implementation mistakes in firmware or source code.
The review can stay at architecture level or follow selected trust paths into implementation, firmware and protocols.
The primitive can be correct while the system is still broken.
Provisioning → Shared identity → Fleet impact
Device credentials are generated correctly but reused across a product line. Compromise of one device enables impersonation of others.
Signing → Update → Persistent compromise
Firmware signatures are correctly verified, but an old trusted key or rollback path still authorizes vulnerable firmware.
Protocol → Nonce reuse → Key recovery
The encryption algorithm is sound, but protocol state causes nonce reuse under a recoverable error condition.
Scope follows the trust model.
Architecture
Keys, identities, signing systems, trust anchors, protocols, product lifecycle and the components performing cryptographic operations.
Attacker assumptions
Physical device access, extracted firmware, compromised client, network attacker, malicious user, leaked credential or another agreed starting point.
Technical depth
We review the trust model first and follow the areas where implementation determines whether the cryptographic assumptions actually hold.
Source code is useful but not always required. Firmware, protocol traces, architecture documentation and test devices can also provide the required evidence. Where the trust question crosses firmware, protocols or device architecture, the review follows those implementation paths as needed.
What you get
Trust-model findings
Where cryptographic assumptions break across components or lifecycle states.
Implementation findings
Concrete weaknesses in key handling, verification logic, protocol behavior or cryptographic implementation.
Exploitability context
What an attacker actually gains and which assumptions are required.
Remediation path
Technical changes needed in architecture, key lifecycle or implementation, with retesting where appropriate.
- TRUST
- device certificate
- PATH
- extract credential → clone identity → authenticate backend
- IMPACT
- device impersonation
- SCOPE
- fleet-wide
When this review fits
Need the review to support a regulatory requirement?
Cryptographic controls, key management, secure update and identity mechanisms can form part of product-security requirements. Where useful, findings can be mapped to relevant technical requirements.
Dr. Ewan Fleischmann
PhD cryptography · 25+ scientific publications · 22+ years IT security
OSCP · OSCE · CISSP
Building a product that needs serious security testing?
Tell us what you're building, the current development stage and what you want tested. The scope follows from the product.