Enhancing API
Security with
Runtime
Secrets &
Attestation
PRESENTED BY: Ted Miracco

2
Ted: Defense Electronics -> RF/Microwave CAE -> Electronic Design
Automation -> Anti-Piracy Technology -> Mobile App & API Security
Skip: Chip Design -> Reconfigurable Computing -> HW/SW ->
Embedded & Crypto Acceleration -> Mobile and API Security
approov.io
tedmiracco skiphovsmith

3
Outline
● Mobile Attack Surfaces
● Hiding API Secrets in App
● Moving Secrets Off Device
● App Attestation
● Summary & Next Steps

4
5 Mobile Attack Surfaces
● Attackers can use their
devices, emulators,
environments
for reconnaissance
● Better reconnaissance,
the more profitable
attacks

5
Danger - Hardcoded API Keys
● In the Headlines…
○ Automotive
○ Retail
○ Fintech

6
Attack: Static Analysis
● Search for high-entropy strings
● Use static analysis tools like
MobSF, JADX, AndroGuard
● Keys could be constants,
resources, or inside NDK
● Surprising how often this yields
results

7
Recently Published “Secrets Report”
● Looked at the top 200
Financial Apps - Sensor Tower
● Downloaded the APKs
● Performed Static Analysis
○ apk_api_key_extractor
○ Git Leaks
○ Trufflehog
● Categorized the Findings
● Grouped the Results by
Application Type and Country

8
Key Findings

9
Report Findings - By Country

1
0
Findings by Industry

Secrets
Hide &
Seek

1
2
Initial Defense: Obfuscation
● Obscure hardcoded secrets,
program flow, and security
code
● Use R8, ProGuard, or others
● Trade obscurity vs run time cost
● If a secret is valuable enough, it
may be reverse engineered

1
3
Attack: Run in Debugger
● Though secret is hidden in
code, it's still exposed in the
run time, go after it there
● Analyze code flow and call
signatures to identify values
exposed at run time
● Replace key functional blocks

1
4
Defense: Run Time Checking
● Block running in debugger and emulator
● See https://github.com/scottyab/rootbeer,
for simple approach
● Adds more functionality to protect and to
be protected
● Attacks evolve over time, do detection
tools keep pace?

1
5
Defense: Play Integrity
● Stronger form of run time
checking which guards
against rooting, tampering,
and repackaging
● Requires Google Play services
● Time and quotas may limit use
● Note that the verdict is evaluated off device

1
6
Attack: Manipulator in the Middle
● Pivot to the channel
● Manipulator pollutes the
device trust store and spoofs
the service identity.
● Manipulator decrypts and
reads and/or manipulates
credentials and API
calls/responses.

1
7
Defense: Certificate Pinning
● App compares public key
fingerprint of presented and
expected certificates.
● Fingerprint can be specified
statically in the android
manifest file or specified at
networking client
construction.
● Fingerprint is not a secret, but
should be write-protected.

1
8
Attack: Bypass Certificate Pinning
● Add instrumentation frameworks
to hook functions without
tampering
● Objection and Frida can detect
and bypass OkHttp pinning
● With obfuscation, may need to
search for function call signatures
blog.nviso.eu/2019/04/02/circumventing-
ssl-pinning-in-obfuscated-apps-with-
okhttp/

1
9
Defense: Trust On First Use
● On first launch, your app
requests some primary secrets
● Primary secrets no longer
hardcoded but are placed
in secure storage
● Primary secrets may be used to decrypt other hard coded
secrets
● Assumes app & channel are initially trustworthy and
storage is safe
Store secrets in secure storage
On first launch, request secrets

2
0
Defense: Harden Channel
● Use short-lived JWT Tokens
○ Use API secret to sign JWTs
○ Secret not exposed in channel
● Sign or encrypt API messages
○ Increases anti-tampering or
confidentiality
○ Requires more secrets, time, and
functionality

Moving
Secrets Off
Device

2
2
Hide & Seek Observations
Upsides
● Loading secrets remotely (TOFU) avoids
hardcoding them
● Play Integrity evaluates verdicts off app
● JWTs do not directly expose secrets in the
channel
Downsides
● TOFU requires blind trust
● More protection capabilities mean more
secrets and more functionality to hide
● Frequent code updates are required as
attacks evolve

2
3
Design Objectives
● Keep no secrets in app at rest
(in code or storage)
● Minimize amount of security
functionality in app
○ Measure app and run-time
environment
○ Make security decisions off app
● Provide live updates to both secrets
and security

2
4
Proposed Architecture
Protocol: Request - Measurement - Verdict - API Call - Validation

2
5
Making a 1st Party API Call
If app attests as healthy, a properly-signed token is validated by the
1st party recipes service

2
6
Making a 1st Party API Call
If app attests dirty, an improperly-signed token is rejected by the
recipes service

2
7
Changing the Signing Secret
● Ops team changes secret at the service and the gateway.
● Each app’s next attestation is signed with the new secret.

2
8
Making a 3rd Party API Call
● If app attests clean, the 3rd party API key is passed to the SDK.
● The SDK rewrites the API call to use the API key.

2
9
Changing an API Key
● Ops team changes the 3rd party API Key at the service.
● Each app’s next clean attestation returns the updated API key.

3
0
Managing Certificate Pinning
● Ops team changes certificate at the app auth service
● The next attestation updates the certificate, and the SDK generates a
new certificate-pinning client

3
1
Signing a Message
● If app attests clean, the message signing key is passed to the SDK.
● The SDK rewrites the API call after signing the message.

3
2
Updating Security Live
Security Posture
● Changing security posture is simply a
change in how measurements are used to
decide the attestation verdict
● Ops team can change security policies at
the app auth service
● Full measurements are still being reported
Security Enhancements
● Cannot update dex code of the app, but
can reconfigure the measurement service
inside the SDK after a clean attestation

Summary
and Next
Steps

3
4
Mobile Application Security
Verification Standard
● Impede Dynamic Analysis and Tampering
○ All detections can be split into measurements and verdicts
○ Detection and response are separated and further protected by
on/off app split (stealthy)
● Device Binding
○ Unique IDs enable different security policies per device and app
● Impede Comprehension
○ Small footprint SDK and auth channel can be rigorously shielded
○ Other portions of an app can be independently obfuscated
● Impede Eavesdropping
○ Certificate pinning and message encryption can be managed off
device
Resilience is strengthened by having secrets never at rest,
splitting measurement from verdict, and live updating:

3
5
API Secrets Exposed
● 23% Financial Applications
Immediately Revealed Secrets
● Code Obfuscation Ineffective
○ 93% with Obfuscation
○ 96% without Obfuscation
● Only 4% Used TLS Certificate
Pinning
● Vulnerabilities exist both at rest
and at runtime

3
6
App Auth as a Service
● Removed secrets in app code
and storage
● Minimized security
vulnerabilities in app by:
○ Measuring conditions in app
○ Deciding security verdicts off app
● Provide live updates to secrets
and security
● Provide live telemetry and
forensics

Thank You
approov.io
ted.miracco@approov.io
skip.hovsmith@approov.io

3
8
Questions
● How expensive is an attestation, and how often should a
running app be re-attested?
● What's the relationship between user authorization and app
attestation/authorization?
● Why is remote attestation better than really strong in-app
self-protection?

3
9
Man-in-the-Middle Attacks
MitM attacks occur when an attacker intercepts or manipulates mobile
device communications to gain access to sensitive information. Apps
were considered protected if pinning is detected in the network config
file and no other red flags are raised. They were rated vulnerable if (1)
user-generated trust anchors were permitted, (2) cleartext traffic its
permitted for non-localhost domains, or (3) Android SDK API level
below 25 is declared in the Android Manifest.