Fernando de Oliveira, Daiane Galvão, and Wesley Rodrigues present advanced strategies for securing mobile operations by linking requests to hardware-backed device keys, providing detailed threat modeling and practical architecture guidance.

Securing Sensitive Mobile Operations with Device-Bound Request Signing

By Fernando de Oliveira, Daiane Galvão, Wesley Rodrigues

Modern mobile apps are often a gateway to highly sensitive services—financial transactions, healthcare, government, and enterprise workflows. While conventional authentication (OAuth, MFA) confirms user identity, it cannot always guarantee that a request is coming from an enrolled, untampered device. Attackers can replay stolen tokens from emulators or cloned environments, creating a critical gap in mobile security.

The Case for Device-Bound Request Signing (DBRS)

DBRS introduces cryptographic signatures generated by hardware-based keys established during secure enrollment. Every API request is signed by the unique private key, ensuring requests are both user- and device-authenticated. Backend services validate these signatures using a device registry, cryptographically assuring that only the original device can make authenticated requests—even if credentials are stolen.

Key Mechanisms

  • Hardware-backed key generation: On first-time enrollment or after app reinstall, devices generate non-exportable keys (e.g. iOS Secure Enclave, Android Keystore), binding user and device identity.
  • Proof of possession: Each API call is signed with the hardware-backed private key, ensuring origin authenticity.
  • Backend verification: Public keys are retrieved from a registry, and each signature is checked to confirm the device and user match the registered, enrolled pair.

Addressing Traditional Authentication Gaps

While mTLS, TLS pinning, and payload encryption protect transport, they don’t prove the requesting device’s integrity. Newer standards such as DPoP and device-bound session tokens enable sender-constrained credentials but require secure device onboarding and long-term key protection.

Threat Model: STRIDE Analysis

A detailed STRIDE table outlines how DBRS mitigates spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, while also listing gaps and complementary controls—such as step-up authentication for enrollment, risk-based policies, continuous attestation, and runtime protection ( RASP).

Securing Device Enrollment

Because initial trust establishment is the weakest link, best practices include:

  • Step-up authentication: Require extra verification for device enrollment, like biometrics or push confirmations.
  • Key attestation: Use platform APIs (iOS DeviceCheck, Android Key Attestation) to ensure keys are hardware-generated.
  • Device risk checks: Enforce OS/binary integrity, root/jailbreak detection, risk scoring, and manual review for suspicious enrollments.
  • User notifications: Alert users about new device enrollments, enabling rapid revocation.
  • Approval workflows: For high-value operations, require administrator sign-off or probationary activation.

Design and Operational Considerations

  • Algorithm selection: ECDSA (ES256) and Ed25519 offer fast, secure, and hardware-accelerated signatures. RSA may be required for compatibility. Prepare to evaluate post-quantum options (ML-DSA, SLH-DSA, FN-DSA).
  • Compatibility: Support for hardware-backed key storage varies by platform/version; provide software fallbacks with additional risk controls where necessary.
  • Performance: Expect minimal latency and increased battery drain on older hardware. Optimize backend caching and monitor registry reliability to avoid bottlenecks.
  • Observability: Track signing errors, anomaly detection, and audit logs for investigations.

Tradeoffs and Limitations

Implementing DBRS increases development and operational complexity, may impact performance, and does not solve all mobile security challenges (e.g., pre-enrollment compromise, runtime malware, malicious device owners). DBRS should be layered with least privilege, anomaly detection, and secure development practices.

Reference Implementation

A practical device-bound signing sample is available on GitHub, demonstrating secure enrollment, signatures, and post-quantum algorithm integration.

Conclusion

Device-Bound Request Signing offers robust, device-centric assurance for high-value mobile operations, aligning with zero-trust ambitions. When combined with behavioral analytics, continuous authentication, and layered security controls, DBRS becomes a cornerstone of resilient, modern app architectures.

This post appeared first on “Microsoft Blog”. Read the entire article here