Financial services
TrustKey
Non-repudiable transaction approval for a retail bank
A mobile authenticator issuing a certificate per device, with private keys held in hardware, so an approval is provably from that device and no other.
This example comes from the technical delivery experience behind AussieSync. It does not necessarily represent a project contracted directly through AussieSync.
Have a process like this one? Tell us about it.
01 Problem
A bank needs to prove a transaction was approved by a specific customer on a specific device. A shared secret cannot do that.
- One-time codes can be phished or relayed in real time by an attacker.
- A credential stored in application space can be lifted off a compromised device.
- A disputed transaction needs evidence, not an assumption about who approved it.
- Enrolment itself is an attack surface if the device is not attested at registration.
02 The solution
A certificate authority issuing per-device certificates, with private keys bound to hardware and challenge-response transaction signing.
- Each device receives its own certificate at enrolment, rather than a shared secret.
- Private keys are generated in and never leave the hardware keystore.
- Approving a transaction signs a server-issued challenge, binding the approval to it.
- Device attestation at enrolment blocks registration from a compromised device.
- Because the key cannot be extracted, approval is non-repudiable.
03 Technical approach
Every choice earns its place.
- PKI & Certificate AuthorityPer-device certificate issuance and lifecycle.
- HSM & hardware keystoreKeys generated in hardware that cannot export them.
- Device attestationVerifies device integrity before enrolment.
- Go & PostgreSQLIssuance, challenge signing and audit records.
04 Outcome
Non-repudiable transaction approval, with device binding that prevents credential lifting.
- Non-repudiableapprovals, provable after the fact
- Unliftablecredentials, because keys never leave hardware
- Attesteddevices verified before enrolment