The document discusses operational security (opsec) and the pitfalls of using cryptography, emphasizing that not only is it vital to keep secrets, but also to not appear as if one has secrets worth hiding. It highlights various opsec problems with encryption, including the retention of metadata, the risks associated with SSL/TLS certificates, and how poor tech decisions can lead to exposure. Ultimately, it argues that effective opsec requires careful consideration of the adversaries involved and the notion of appearing 'normal' to avoid drawing unnecessary attention.

1. OPSEC CONCERNS IN USING
CRYPTOGRAPHY
OR:
HOW YOUR BAD TECH DECISIONS
HELP ME PUT YOU IN JAIL
JOHN BAMBENEK
CRYPTO & PRIVACY VILLAGE, DEFCON 24

2. BIO
• Manager, Threat Systems @ Fidelis Cybersecurity
• Lecturer in CS @ University of Illinois Urbana-Champaign
• Run several takedown oriented groups on malware threats
• Crafter of Artisanal Molotov Cocktails

3. DEMO
• Who here has a cell phone?

4. TL;DR - PATTERNS AND NORMALCY
• Surveillance does not scale for large datasets:
• People, malware, packets on the internet, etc.
• There has to be multiple layers of filtering and scoring to
determine priority of tasking resources.
• Some targets are specifically and explicitly tasked, everything
else is all subject to some level of pattern matching and
prioritization.

5. REMINDER
• You are not a normal.
• This is a normal:

6. WHAT IS OPSEC?
• Operational security: keep what you don’t want known
unknown.
• Part is keeping secrets.
• Another (more important part) is not looking like you have secrets worth
having.
• Basic security matters (we’re still not using passphrase-less
keys are we?)
• Compartmentalization: everyone has compartments.
• Signaling vs. Communication

7. RISK ASSESSMENT?
• Who are we hiding from? What are their interests and
capabilities? What is “sufficiency”?
• Intelligence services, law enforcement, and their friends (like
me)
• Criminals or other malicious actors
• Comcast

8. DON’T THINK YOU ARE A TARGET?
• How many people here have admin/root on infrastructure they
don’t own?
• Our government has already said that is the exact kind of
people they are targeted (even before those of you how have 0-
days, etc).
• You don’t think the US is the only one who does this, do you?

9. WHY OPSEC CONCERNS WITH CRYPTO?
• Thought process starting in tracking mobile malware, Android
Apps need to be signed.
• As an investigator and intel analyst, I LOVE free-form text
fields. (more later)
• As technologists, crypto is hard and many of us still don’t
understand it’s limitations.
• Encrypt all the things may not be the best option in certain
circumstances.

10. WHY OPSEC CONCERNS WITH CRYPTO?
• Two parts of OPSEC:
• Want to hide the secrets
• Want to hide the fact you have secrets
• Crypto is great at the first one.
• Crypto often loudly yells that you are the second guy.
• Note- Everyone I’ve helped put in jail is there because they
screwed up their OPSEC.

11. WHAT’S WRONG WITH THIS?

12. OPSEC PROBLEM #1 WITH ENCRYPTION
• Not everything is encrypted.
• Above example, the DNS request which is “good enough” to know what
you’re doing.
• Even in a “perfect” crypto world, the session metadata isn’t
encrypted.
• Source, Destination, Time, Inferences of size of communication…
• If I know who you are calling/texting, sometimes that’s enough to make
inferences.
• The HEIST attack at RSA, while overhyped, is an example.

13. CAREER DECISIONS
From: Kevin Mandia kevin.mandia@fireeye.com
To: John Bambenek john.bambenek@fidelissecurity.com
Subject: Job Offer for VP role
-----BEGIN PGP MESSAGE-----
Version: GnuPG
v2hQEMA/RALgVP0CqhAQf+K6nsUfJ2JZKEJQIqcuywV3xwtpRR4bQhZblCPQcSJwbPzgh/q4zoIZi/yy5XLTGQ
6p2WrQH+0UfmQmyu44v1VPBF+3JFReG1IJvJNXPQPcH13gGiyLRj4A1r32EgieHIxbfN+TWvrrl4M1BOQ0dQ
2UXkrInj2/5xLFl2HunrDZiqSQcpZrqwTCJf+CJXlZJJKmQRNz76ohQzVbJFyqV/zIKD26DBMGKRB0v2gYjhTRW
V9cuHLf9JSNA5ZdmyskcEM0PFCzSnv9Mx6VprsbWGeb6dbkwW1kM+xgdbcSnyEuRyVFUoOPTb1E0q5rDN
wVZknUZAq1pjYnn+D+zoVRyz99LA0AFLgF8T3gQaQqIQErW3OlVxQKb58DKv6lM4x5oxlI4sv1je6HT7+PK
nCvmbhRRWFpWVkyot5Fam0xILWR2UbE+/1a3nSDySnGnzNNq2e2EDrKA+CNVFGXd3HfFZgzAp2foEP/Z+
kbU9O/2QvwS/jBbclti9SPK0PNuPa321TpD/Qoz0yuPWhpOrYp/kxN7nJ9FW5OWI+r5dEB29yasAeeCoMsxJz
yzo7TnKQEOP5Ty/Sae+K0yY4Do7oakGQVKyEkQUzQlOc0bwAwINavXJsov2nlGmV7eRJgr8xzDc6DCHuZm
3URfqKvt37Vbr1kpPs6mjtHSw0iJJ1tvk9tbiElfAQvXr3KyQlGhqNjtPC8TEYnWeIlq27OfQ6iLarTtkYX3oJLW5NlI
lvSVLICzB+yejDP+8HMVKF1s8Nc6D9V78dyHBPdx8wafPUYf4XeImux1m1SFdRJjvYhaU5famV0hPR22Tui+e
EPSvzKWDa4VDT/jIENl9TSPH3LqpXEQVYoL2Cw/+0lBpWE90+Hlw2w8==Iidd
-----END PGP MESSAGE-----

14. AND THERE’S MORE
$ gpg -vvvv text.gpg
gpg: using character set `utf-8’
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v2
:pubkey enc packet: version 3, algo 1, keyid F4402E054FD02AA1
data: [2046 bits]
gpg: public key is 4FD02AA1
:encrypted data packet: length: 400 mdc_method: 2
gpg: encrypted with RSA key, ID 4FD02AA1
gpg: decryption failed: secret key not available

15. IF YOU HAVE THE KEY, YOU GET MORE
:secret key packet: version 4, algo 1, created 1442844965,
expires 0 skey[0]: [4096 bits] skey[1]: [17 bits] iter+salt
S2K, algo: 3, SHA1 protection, hash: 2, salt: 1edfd8aa175bb427
protect count: 65536 (96) protect IV: 8a d6 c0 76 0e
c4 86 5c encrypted stuff follows keyid:
0F3B1D99BBB8C31E:user ID packet: "John Bambenek
<john.bambenek@fidelissecurity.com>”
Anonymity with PGP is hard. See Tom Ritter’s Deanonymizing
Alt.Anonymous.Messages talk: https://ritter.vg/p/AAM-
defcon13.pdf

16. KEYSERVERS
• With a Key ID, you can cross-search keyservers to find the
identity.
• Old keys never die.
• Many people have multiple emails tied to the same key (not
usually a good idea).
• People reuse same SSH keys for authentication across
environments.
• Silk Road – Dread Pirate Roberts compartmentalization screw-
ups should be required reading.

17. BOTTOM LINE
• The argument for shutting down “safe spaces” for terrorists to
communicate is stupid. Never drive a known into an unknown
without some return.
• Lots of useful data still available in metadata.
• Required reading: @thegrugq
• https://medium.com/@thegrugq/intelligence-services-are-
scary-af-40f7646ea117#.o6hszwm7g

18. OPSEC PROBLEM #2 WITH CRYPTO
• SSL/TLS Certificates, Signing Certs create all sorts of new
metadata
• Geolocation, Identity, Serial Number, Creation/Expiration Dates
• CAs have one job: to verify identify of the owner of certs they
sign
• Have I said I love free-form text fields?

19. YOU HAVE ONE JOB
# ./letsencrypt-auto certonly --standalone -d gmail.com
An unexpected error occurred:
Policy forbids issuing for name
# ./letsencrypt-auto certonly --standalone -d fireeye.com
Installation succeeded.
# ./letsencrypt-auto certonly --standalone -d illinois.gov
Installation succeeded.

20. IT GETS WORSE
• What happens when someone gets a wildcard certificate?
• What about when a security company gets their own CA
certificate?

21. MORE CERTIFICATE FUN
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
fa:21:6b:2c:8e:6c:35:f6
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=EU, ST=Oregon, L=Cincinati, O=Oracle Corporation, OU=Oracle, CN=Oracle
Developer/emailAddress=admin@oracle.com
Validity
Not Before: Jan 6 16:33:13 2015 GMT
Not After : May 23 16:33:13 2042 GMT
Subject: C=EU, ST=Oregon, L=Cincinati, O=Oracle Corporation, OU=Oracle, CN=Oracle
Developer/emailAddress=admin@oracle.com

22. MORE CERTIFICATE FUN
• Malware builder always used the above cert when it resigned
trojanized app.
• Now it’s trivial to find the “many” apps in the Google Play store
with that malware.
• Basic statistically analysis, hunting for geographic oddities, etc
makes hunting mobile malware easy.

23. HOW TO FAIL AT TLS
Data:
Version: 3 (0x2)
Serial Number: 522427837 (0x1f239dbd)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FR, O=assylias.Inc, CN=assylias
Validity
Not Before: Jan 17 05:26:19 2015 GMT
Not After : Dec 24 05:26:19 2114 GMT
Subject: C=FR, O=assylias.Inc, CN=assylias

24. HOW TO FAIL AT TLS

25. ONE LAST POINT
• SSL/TLS certification information is searchable with Shodan and
a few other tools specifically for archiving observed SSL/TLS
certs.
• If you re-use certs, it makes it easy to correlate your activities
and break your compartmentalization.

26. OPSEC PROBLEM #3 WITH ENCRYPTION
• Encryption (to some) is inherently suspicious.
• What is actually suspicious is abnormal behavior.
• All profiling (and surveillance) is based on this concept because
it is impossible to monitor everyone completely. Target
selection is important.

27. EXAMPLE #1

28. EXAMPLE #2

29. VPNS
• I may not know what you’re saying, but I know when you’re
saying it.
• All the “privacy” VPN services are known and their IP space is
profiled.
• You could set up your own VPN, but you immediately lose the
privacy using a common service provides.
• And don’t think all those bitcoin services will help you either.
Bitcoin is anonymous but it is NOT private.

30. MAKING ENCRYPTION MAINSTREAM
• We’re already doing it with Let’s Encrypt and other aspects of
PRISM fallout.
• Google now sends email over TLS (**if other side supports it**)
• Tor is not ”normal”
• VPNs to non-corporate endpoints are not “normal”
• Encrypted email is not ”normal”, nor is WhatsApp, Signal, et al…
yet.
• But they can be. We may not look like a sheep, but maybe we
can make the sheep look like us.

31. SOMETIMES ENCRYPTION IS NOT WORTH IT
• When traveling in “less friendly” locations, it may be better not
to draw attention. Border checkpoints are not your friends.
• Tor may hide what you are looking at but it stands out on a
network.
• Many criminal and intelligence professionals use electronic
means for signaling and then have a conversation in a preferred
secure location.

32. SOMETIMES ENCRYPTION IS NOT WORTH IT
• How many people here have secure wifi at home?
• Note, digital forensics is good at figuring out the bits. It can be
hard to figure out what’s going on in actual meat space.
• Sometimes ambiguity is your friend.

33. OPSEC PROBLEM #4 WITH ENCRYPTION
• Encryption doesn’t protect you against stupid mistakes.
Including by others.
• It’s the stupid stuff that gets you.
• Password re-use, even when hashed and salted can taint
compartmentalization.
• Passphrase-less keys publicly available on the web

34. STUPID MISTAKES BY OTHERS
• All security is based on trust.
• Using a hacker bulletin board? How can you be sure they are
fully patched and haven’t had their database dumped?
• Are you sure your encrypted messenger isn’t just giving your
data away anyway?
• Think it can’t happen? Look at Wall of Sheep upstairs. Or ask
Ashley Madison.
• Important point, password hashes become identifiers.

35. ALL ENCRYPTION NEEDS TO BE
EVENTUALLY DECRYPTED
• Cracking crypto is hard… attacking endpoints is easy. Attacking
people’s stupid mistakes is trivial.
• If I already own your box, all your encrypted comms are
worthless.

36. PASSPHRASE-LESS KEYS
• You may be in a scenario to have to give up your files… if your
keys are there it’s game over.
• Virustotal keeps all files that are submitted to it and makes
them available via commercial API.
• You can use Yara to find things, like all files that have “BEGIN
RSA PRIVATE KEY”.
• The search “maxes” out the results at 10,000. Of those, over 85% had no
passphrase.
• SSH keys don’t have targeting information in them directly.
• PGP keys do though, and you can search for those in VT too 

37. WHAT TO DO ABOUT IT ALL?
• It depends on what adversary you care about.
• Free-form text fields are your worst enemy.
• Layers help.
• Compartmentalize (if you’re doing interesting things while
using tor from home, you’re doing it wrong).
• Look and smell like a normal. Sometimes waiting or not
encrypting is a better option.

38. TOOL 1 – ANDROID-CERT-GENERATOR
• https://github.com/uiucseclab/Android-Cert-Generator from UI
Security Lab students.
• I wanted to figure out how to defeat my own analytics.
• Problem: Android malware requires you to write a fully-functioning
app or to trojanize an existing app but have to resign it. Need a way
to create believable but fake signed APKs because you lack the
private key.
• Uses same details as previous signed cert.
• Checks google play store and wolfram alpha to generate the information.

39. BOTTOM LINE
• #DFIU

40. QUESTIONS?
• For Fidelis: john.bambenek@fidelissecurity.com
• For Univ. of Illinois: bambenek@illinois.edu