Assumptions about the powers of the Adversary
CS 463
Lecture, Dr. Lawlor
The big problems with keeping secrets are:
- It's pretty easy to capture data going across
networks. "Packet sniffer" tools like Wireshark
allow you to see every byte in every packet that crosses your
network card. This means if you send secrets across the
network, they will get out.
- Solution: important network data needs to be encrypted, so
even if it's captured, it won't reveal anything.
- It's also pretty easy to "spoof" network data,
fabricating packets either entirely on your own, or based on
captured data.
- "Record and replay" is where you capture data, then
spoof it, possibly repeatedly. Consider, for example,
recording the "deposit $1000 at ATM" network traffic, and
spoofing that traffic to the bank several hundred times.
- "Man in the middle" is where data is captured in
realtime, recorded or modified, and then spoofed.
Sufficiently sophisticated software can do this in realtime
with surprisingly low latency.
- It's tedious but straightforward to reverse-engineer
the operation of computers. Some languages like Java make
this really easy (the bytecodes are very friendly to analysis);
it's more work yet still entirely possible in a
compiled-to-native language like C++; and hardware solutions can
require sophisticated electrical equipment, but are still
vulnerable. This means if you encode the secret into a
computer program or hardware, or if the security of the
encryption scheme depends on a secret algorithm, you're sunk.
- Any serious encryption algorithm gets widely published, as a
way of demonstrating it's still secure even if you know the
trick. The remaining parameterized secret is known as a
"key", typically a block of random-looking binary data.
- See: the Caeser cipher ("Sir, we've captured one of Caeser's
messages, but it's in some sort of code." "Hmm.
Could it be... the Caeser cipher?"), HDMI HDCP encryption, and
every game console ever created.
- It's common the attacker actually knows the plaintext,
or some part of it (for example, top secret data might begin
with TOP SECRET). Knowing both the plaintext and
ciphertext makes cryptanalysis much easier.
- It's common to assume the attacker can even generate the
plaintext, allowing them to do differential
analysis. For example, an ATM's encrypted communication
with the bank during the attacker's legitimate transaction is
bound to include the transaction amount, which can be carefully
chosen by the attacker (e.g., deposit a series of checks in the
amounts of $1, $10, $100, etc).
And of course, it's even worse than that:
- Laptops get stolen. Tom Cruise sneaks into your
facility. The truckbomb is just a decoy so the fake
"police" can get into your data center.
- All data at rest really needs to be encrypted. It's
important to disable virtual memory, since swap file
reconstruction is well known.
- "Two-factor authentication" includes something you know (a
PIN or password) plus something you have (a keychain
encryption device). It's quite a bit harder to steal
them both.
- Hardware is surprisingly leaky to the sufficiently
motivated. DRAM can retain data for as long as days.
There are serious issues with erasing both magnetic drives
(thermal recalibration shifts and bit-edge effects) and flash
storage. Electromagnetic radiation can transmit secrets
for miles: see TEMPEST standards for radio transmission
shielding (CRT displays are notorious for this). Clever
folks with telescopes have reconstructed ethernet packets from
the blinking pattern of the activity LED.
- Cleartext secrets should never really be written to any
storage, if possible.
- Shred and incinerate hardware onsite?
- Tinfoil hats--for your hardware?
- You can't even trust your own employees ("the insider
threat"). Maybe one of 'em is a mole working for the
other side. Maybe they're being blackmailed, or having
mental health issues. Maybe they're OK, but their laptop
or smartphone is infected with targeted spyware.
- "Random enhanced employee interrogation techniques including
waterboarding will continue until the insider threat is
eliminated" is not a useful management strategy in most
organizations.
- The separation of responsibility is standard in the
financial world, so no single employee can cause disaster
independently.
- Kernel-level tools can prevent portable storage devices from
being mounted, and telemeter in an alarm when this is
attempted. (Machiavellian version: the kernel *appears*
to mount the storage device correctly, but instead of copying
out the real secret files, they copy decoy versions missing
the good parts and including a low-key monitoring system like
a web bug. Think honeypots.)
- Tools like watermarks can detect which insider leaked a
document.
- Watch and analyze the *outgoing* network data, not just
incoming.
There's a sort of sliding scale of attacker sophistication in the
crypto world, ranging from realistic "cipher capable of reminding
a script kiddie that he didn't actually want to read your email"
to the science fiction "cipher capable of resisting the net
compute power of the entire planet throughout hundreds of years of
Moore's law." Realistically, past a certain point additional
crypto security is not useful, because it would be easier to just
buy your secrets--would you turn down a million dollars? How
about a ham sandwich, after they've starved you for a week?