Notes from CCC 2008

While attending CCC 2008, I was making notes, as usual (see DIMVA, DeepSec). Slides for some talks are available on talk pages in the Fahrplan, or try to find a recorded video. I hope the notes are useful.

“Nothing to hide”

• “Nothing to hide” does not make sense:
  • Where are the conference organizers keeping the money?
  • Who knows the passwords?
• We are somewhat “lucky”: weak WiFi cryptography allows “anonymous” internet connections
• OLPC might be in violation of GPL because it does not give source code to children

The Trust Situation

• Germany: if you don’t know what others know about you, you might adjust your behavior (fear what they know), which is considered in conflict with being a “free person”.
• surveillance unaviodable => data protection law instead
• people’s decisions are irrational heuristics, reduced number of hear-say “facts”, bias towards own values / group values
  • people fear data isn’t protected, hide information pre-emptively
  • permanent databases: people hide illnesses, students with bad records give up completely
• to make surveillance/data protection understandable, make it simpler, make data protection more drastic/visible
• that’s impractical => either allow people to avoid surveillance, or give up the pretense of determining who keeps the data

Security Failures in Smart Card Payment systems

• UK process:
  • card reports account #, …, magnetic strip data copy
  • receives transaction description, PIN
  • returns PIN verification result (handles incorrect PIN counter internally), authorization code
• magnetic strip data copy + PIN can be used for a fall-back transaction with a cloned card
• => PIN entry device should be temper-proof, are certified (Visa, EMV, PCI, …); VISA certification requirement: tampering requires >10 hours or >$25,000 per device
• tamper resistance protects bank’s keys, not the PIN – which is transferred unencrypted
• Dione Xtreme tamper-resistance:
  • tamper switch that wipes keys when device is opened, but easy to drill through in other places
  • CPU in epoxy, no tamper detection
• Ingenico:
  • tamper switch, protected by a steel plate with a sensor mesh around it
  • “buttons” that wipe the battery when the front panel is removed
  • meshes that detect PCB corruption
  • CPU wrapped in a sensor mesh
  • contains place for expansion cards, which can be used to hide a device;
  • screw holes for fastening the expansion cards are a hole in the mesh, which can be used to tap the communication line
• or double-swipe => copy the mag stripe, then watch the PIN
• or relay the communication from a “restaurant” to e.g. a diamond shop
• possible improvements:
  • no copy of magnetic strip on chip
  • encrypted PIN communication – even if magnetic strip copy is already prohibited
• customer considered liable for PIN fraud per voluntary banking code =>incorrect incentives
• certification contracted for by the manufacturer => incorrect incentives
• More about this research

Hacking the iPhone

• “application processor”, “baseband modem”: separate security system for each
• application CPU:
  • OS: lobotomized OS X (launchd, system libs); shell is “SpringBoard”
  • lockdownd = bridge for connecting between computer and iPhone sockets
  • / “read-only”; /private/var read-write: only a logical distinction by FS
  • protection:
    • 3rd party apps on user partition, signature necessary (verified by execve()), run as user mobility => cannot overwrite the system
    • kernel signed, writable only by root
  • boot process:
    • boot RPM loads “LLB” from a NOR flash
    • LLB loads image list, next stage, checks signature, runs iBoot
    • iBoot: populates device tree, loads kernel, executes it; checks signatures on everything
  • LLB is not signature checked
  • boot abort:
    • downloads root & kernel to ramdisk, uses it to reflash boot/kernel
    • more signatures, hashes, encryption…
    • when checking a recovery ramdisk signature, the boot ROM contains a buffer overflow => can be exploited to load any ramdisk => patch anything
  • mistakes: gradual roll-out that allowed learning about the system (old versions unencrypted, trusting the PC, running as root…)
• baseband:
  • boot: ROM=>boot loader => firmware; “Nucleus” kernel
  • no recovery mode => can be bricked
  • boot loader: allows serial payload if ROM is “blank”, there is a signature check
  • ROM checks boot loader’s signature
  • 3 entry points: normal/service/trusted module
  • bugs in v1:
    • address computation bugs allowing overwriting “protected” areas
    • RSA implementaiton vulnerable to Bleichenbacher attack => can fake signatures
  • v2: protected => patch loaded firmware in RAM instead of modifying the flash

Advanced memory forensics: The Cold Boot Attacks

• Research homepage
• RAM is not designed to erase on power off – there’s only a “noticeable probability” of bit flips
• cold boot attacks:
  • deliberately crash a PC, then restore power to RAM and dump it
  • wake a sleeping/hibernated laptop (to a password prompt), then crash and restore power to RAM
• tools to dump after a reboot:
  • USB stick or network boot – to dump memory data
  • PXE is untrusted => PXE may be used to boot a dumper, which sends it to a broadcast address => the receiver of the dump is not necessarily identifiable
• detecting key schedules, correcting bit errors:
  • look at 8-byte aligned bits in memory, try to guess if it is a key; this can detect AES keys, supposedly regardless of implementation
  • RSA: even if only 70..75% bits are preserved, the rest can be recovered
• cooling:
  • only necessary when physically removing RAM from a PC (necessary if BIOS is “unfriendly” – e.g. clears RAM)
  • simply restarting at room temperature never lost enough data to prevent key reconstruction
  • even when moving RAM, cool canned air was enough, liquid nitrogen not necessary
• => bugs:
  • BitLocker: basic mode writes key information to disk! => fully automated live CD
  • BitLocker with TPM: does not use TPM for all encryption, key is still in memory
• countermeasures:
  • turn laptops completely off when computer might get out of owner’s control (when going through US customs )
  • require a password to boot external media (but chips can be simply moved to other computer)
  • destroy all key material at screen lock, suspend, hibernate — this can require significant software changes
  • ECC RAM: supposed to be cleared by a memory controller on boot, but that can be bypassed/reprogrammed to make the parity bits available => even more data available
  • encrypted memory (for DRM…, storing keys in tamper-proof HW)
• film script writers clueless: removing DIMM modules with tweezers, cold boot attack a SIM card

Why were we so vulnerable to the DNS vulnerability?

• flaw history:
  • 1999: DJB: 16b is not enough => response: if the TTL is ~1day, there won’t be enough opportunities to try guessing an ID
  • there are many ways to get around the TTL defense
  • if the attacker controls when the query happens, they can send the reply before the genuine one
• “in theory should not matter”
• practice:
  • most web not encrypted
  • e-mail
  • other applications
  • 41% of SSL certs self-signed
  • most non-browser network clients don’t even want a signed SSL certificate
  • automatic updates assume DNS is safe
  • SSL uses e-mail to authenticate certificate receivers
  • “forgot my password” systems bypass SSL authentication entirely
• attack method:
  • send an e-mail => DNS lookup for the receiver’s domain, attacker knows domain IP and port used by the DNS server, poisons it
  • “forgot my password” will send mail, poisoned => I’m an authenticated user => can insert PHP code => can own the box
  • (connection to database host poisoned as well)
  • not a bug in Drupal, …, anywhere – only DNS
• => “need to stop using passwords and only use SSL client certificates”
  • sucks, expensive to manage, fail in some use cases
  • simply: passwords scale => they WILL be used
  • analogically: DNS scales => it WILL be used
• DNS is a good at “federation” – managing a shared name space without conflicts and without trust between users/participants (competing companies)
• everything uses DNS to federate:
  • e-mail’s MX
  • web’s same origin policy
  • SSL/x.509: supposedly distributed, federated, …
    • how do you know which root CA to trust?
    • wildcard certificates difficult to acquire
    • not actually independent on DNS: CN=dns.name
  • password reset e-mails
  • OpenID: uses same origin policy
  • SSL: uses e-mail to check user owns a domain
• DNS is reasonably secure as such and on input, but not on output (replies are not authenticated)
• in practice: used for security ~everywhere because there’s no alternative
• other problems in 2008:
  • VPN software uses SSL, but does not validate the certs
  • cookies received from https:// are by default sent to http://, and almost nobody changes that
  • almost nobody authenticates downloaded code (Java, OpenOffice, iTunes, …)
  • Debian RNGs
  • SNPv3 flaw (Wes Hardakar): challenge-response protocol to authenticate users only verifies the first byte of the response!
  • unifying traits:
    • authentication problems
    • all simple bugs
    • fixes are hard to manage (dependencies, other customers, …; “I love buffer overflows” because the fix is always local)
    • the bugs “blend”:
      • DNS + SNMPv3 = MItM by reconfiguring a router to get the data to MItM
      • bad DNS works around Java socket connection restrictions => can use Java applets to attack SNMPv3
    • all are very old problems, age does NOT predict quality
    • very slow and expensive to repair (DNS: nobody depends on the bug, 2 days to find, 8 months to fix; ~75% patched after a month)
• theory: if DNS was completely secure, some of the design bugs wouldn’t matter
  • VPN software: software must be possible to ship as a test gear, when customers don’t have a SSL certificate, which would require communication between customer, vendor and certificate – too expensive and complex; but if DNS were secure, it could store an authentication hash
  • DNS cannot tell you that a site is HTTPS-only, so you must place a redirect on http:// – which can be MItM attacked
  • automatic upgrades: would Just Work, but SSL is slow and does not scale => people use HTTP and screw up the authentication of the update (certificates…); DNS could be used to distribute hashes of new code
  • storing PGP in DNS => secure e-mail
• don’t blame business guys for poor design caused by needing to work-around DNS
• “DNS was not designed for putting things in DNS”
  • DNS is already used for security – without secure DNS
  • federation: nobody can prohibit putting these things in DNS
• => to do:
  • figure out how to make DNSSEC scale
  • migrate applications to use it
• how the fix was done:
  • identify critical players – Paul Vixie contacted them…
  • met in person – to force making a decision: Paul brought in engineers with decision-making capability
  • agreed to synchronize the release to avoid attacks on slow fixers
  • ground rules:
    • must secure “all names”
    • must secure all authoritative name servers, even if they don’t do anything => must be done in the recursive name server
    • must not alter DNS semantics (break anything): if only 1% fails, the patch will be rolled back
  • easiest fix: DJB: source port randomization: slow, port conflicts when there are other services, problems with firewalls, some kernels don’t handle too many sockets open
  • alternatives:
    • TTL – but there are >=15 variants of TTL bypass, not comprehensive and won’t be (e.g.: query for unknown record type, flood with NXDOMAIN => DNS server must drop all caches => TTL bypassed)
    • use TCP: very bad performance
    • deploy “defense” only when an attack is observed – but DNS requests can be spoofed => defense becomes a DoS
    • resolve 2 or 3 times – breaks akamai
    • vary case in request, verify the reply is the same => extra bits – but a1.11111111 gives only 1 bit
• should there be a midpoint between transition to DNS? somebody working on it
• release handling:
  • talk to personal e-mail providers, the most expected attack targets
  • notified SSL CAs because they verify ownership using DNS
  • autoupdaters: underestimated how many were broken
• testing tool:
  • testing the DNS server used for HTTP, and for SMTP
  • letting clients test without cross-side scripting: for images loaded from a foreign domain, the image size is available => a side channel for cross-domain information retrieval.
• current state:
  • ~75% name servers updated, probably won’t get much better
  • don’t know how many users are protected by this
• other bugs in trusting a gateway, there will be more?
• thoughts on DNSSEC:
  • to be meaningful, root MUST be signed
  • how to make key signing scale? DNSSEC requires a lot of manual manipulation
  • registries and registrars must be able to do this without too much cost / “load”
  • DNSCurve (DJB)
    • requires on-line key signing (key available on DNS server), unline DNSSEC
    • registrars don’t have to do much
    • no code
    • new crypto: the proposed ECC is optimized for speed and non-standard
    • not proven, not specified
    • patent-encumbred
    • per-query crypto (not required by DNSSEC) => 100% CPU at 1/3 load of current systems
    • does not provide end-to-end trust:: secure only if directly talking to authority servers, not cachable => 100x load

Lightning talks (Tuesday)

• lxde.org
• anomos.info ~ encrypted, pseudonymous BitTorrent (assuming a trusted tracker)
• privacyfoundation.de:
  • german privacy foundation: caused by investigations against Tor admins,
  • “Tor partnership program”: foundation legally owns and runs the server (needs root password)
  • training of police investigators
• openpgp card, with smart card reader required => “crypto stick” on USB; will release HW/SW as open source; pre-order info@privacyfoundation.de, €30..40
• OLSR-ng: mesh routing daemon
• hacking botnets and stealing back stolen data
  • “fresh” USB stick contains a bot
  • ~0.95M infected IPs, ~145k users online at one time
• hackable1.org: hackable:1: OS for OpenMoko

Climate Change – State of the Science (Stefan Rahmstorf)

• simple energy balance (long-term): solar radiation – reflection of solar radiation = back radiation (= earth’s radiation out) => change incoming radiation, change reflectivity, or change back radiation
• orbital cycles:
  • CO2 cyclically between 190..290 ppm in the past 4k years
  • currently we’re at >350ppm
  • orbit changes => glacial cycles
  • CO2 concentration rise caused by humans: we know how much we have emitted, the rise is only ~.5 of human emissions – the rest is mostly in the ocean, which is becoming acidic
• effects other than global mean temperature:
  • more frequent heat waves
  • precipitation changes (S Europe drying out)
  • sea level higher by ~.5..1m
  • cyclone strength possibly increasing
• what we want to do:
  • target 2° increase – still supposed to be practical – by reducing emissions to ~50% by 2050
  • a proposed plan for Europe, supposed to cost no more than now

Attacking Rich Internet Applications

• DOM-based XSS:
  • use values of DOM objects that can be influenced by the attacker, output them somewhere or eval() => XSS
  • document.URL, location, referrer…
  • “sinks”: javascript: URIs, …
  • new “sinks”: CSS 3 selectors can read data from the page, will be able to read data from other pages in HTML5; <input> prefilling, style changes
  • document[user_input] can access document.cookie (=> cookie stealing, session fixation); [] notation common in “packed” javascript
  • IE8 XSS filter: stops injections into JavaScript strings, but assignments are still allowed
  • injection into “nice” URLs: /path/to/my/Nicename?… where $Nicename = ../../../something
  • document.domain controlling same-order policy
  • client-side SQL injection on client SQL storage
  • HTML injection inputs: facebook/myspace/IM/webmail, …:
  • document.getElementById() uses name= as well in IE; returns the first matching object if >1 is there
  • document.getElementsBy{Tag,ClassName} in IE[67] accepts id=, name=
• control flow problems: unexpected condition evaluation (“is undefined” vs. “is 0″, etc.)
• concurrency bugs: 1 thread per page, no support for locking; usually no shared state, but that might change
• browser-based DOM XSS:
  • examining what cross-domain iframe can access in parent
  • Fx 2.0:
    • frame.history.go() overridable
    • prohibited attempt to set frame.variable deletes it in the frame => can affect frame’s javascript variables/control flow
    • window.{top,opener,parent,frames} overwritable
  • IE7:
    • frame.opener can be overwritten, used e.g. by tinymce
  • WebKit/Safari/Air:
    • __defineGetter__ on history.$something
  • Opera: window.top
• RIA to subvert html5: “too much accessibility”
  • <input type=uri>, <input type=email>
    • stealing it: set window.onkeydown, on enterKey read value
    • force user to press “down” and Enter to get a value from user’s history: JavaScript game using arrow keys and Enter
• CSS3: [attr^=val], [attr$=val], [attr*=val] matches parts of an attribute value, can be used to read attributes if we can control CSS
• Google Gears:
  • user-controllable cache => allows cache poisoning, affects anything that caches the same data as soon as 1 page is XSSed
  • e.g. google-analytics.com affects “most of the web”
  • can run JS “threads” that load data from other domains => hosting user’s plain text, or even correctly marked XML lets them run in your domain’s context
• attacking Fx extensions: common vulnerabilities: eval() for JSON => network control implies code execution
• opera: scheme: all opera:* URLs have the same “origin”

Vulnerability discovery in encrypted closed source PHP applications

• PHP bytecode: opcode, result, 2 operands, “extension”, source code line #
• most bytecode encryptors don’t remove the line #
• newer encryptors don’t decrypt & pass to original executor, they contain a copy of the executor instead – but it still has the same structure & same dispatch tables
  • find opcode table, patch it to record the opcodes, then reproduce the byte code
  • encrypt all op codes => have recorded versions; guess “optimized op codes” defined in the encryption
• checking byte code is sometimes simpler than grep & inspect, more can be automated (including data flow analysis to find potentially dangerous constructs)

TCP Denial of Service Vulnerabilities

• (originally wanted to find out what outfrost 24(?) found)
• original design: end-to-end intelligence, attacks within the network unlikely
• Paul Watson: TCP reset attacks: reset needs to guess a seq# within a window, which is quite easy with large windows
  • countermeasure: random seq# and source port
• connection backlog: to limit kernel memory usage
  • 2 separate queues: SYN, ESTABLISHED (waiting for accept())
• connection flooding (not SYN flooding) depends on application behavior => applications must:
  • accept() fast enough
  • limit number of total connections – kernel doesn’t! – should be based onactual (kernel’s) memory consumption
• FIN_WAIT1: in kernel, can’t be controlled from user space, timeout is >= 7 min
  • timeout depends on round-trip time, which can e artificially enlarged => up to 16 min!
• peer can make sure the kernel’s send queue is very large => very large kernel memory consumption
  • if window size is 0, window probes are repeatedly sent, connection is never timed out!
• kernel: TCPDEFERACCEPT in Linux: accept() only after data is available => if no data ever sent, stays in kernel queue
• congestion control: can trick a high-banswidth host into exhausting their bandwidth:
  • send ACKs to prevent congestion detection
  • … even before receiving the packet to fake small RTT
  • fixes:
    • change TCP to prove the packets were received
    • drop a segment from time to time to check if peer is truthful
• new possibilities:
  • open a connection, reach optimal connection window; set window to 0 (this does not change the congestion window!)
  • repeat N times
  • open all windows at once
• a burst can indicate full queue, but not really congestion => “shrew DoS”: can DoS by periodic bursts

Banking Malware 101

• classical attack: only one credential per victim
• banking trojan: “somehow” get a keylogger to victims, collect many credentials per victim
• Nethell/Limbo trojan:
  • IE “Browser helper object” using COM
  • stores typed passwords, passwords stored “in the browser”, cookies
  • handles visual keyboards by sending screenshots around mouse click locations
• ZeuS/Wsnpoem/Zbot
  • injects itself into various system processes (services.exe, …)
  • grabs form field contents, injects arbitrary HTML code (e.g. to store some fields in forms, to ask for more personal information)
  • detection: uses specific mutex names
• others:
  • MBR modification
• finding drop zones:
  • honeypots, client-side honeypots: deliberately browsing the web to try to encounter malware
  • malware analysis: cwsandbox: execute in controlled environment, observe
  • some keyloggers only submit data after interesting data is collected or after IE is started => emulate human behavior
• statistics:
  • gigabytes of collected data, 1.5GB the largest one
  • drop zone lifetime ~2 months
  • German targets: Volks- und Reisenbanken, OSMP, Stantander, Fiducia, ABN AmroBank
  • underground prices: bank account: $10..$1k; credit cards: $.4…$20; full identities: $1..$15;, …
• protecting oneself:
  • patch quickly
    • do not click on suspicious links, open suspicious attachments
  • anti-virus
  • Germany: mobile TAN (SMS with transaction description and TAN)
  • indexed TANs vulnerable to MitM – seen in the wild
  • in general, 2 factor auth helps
• honeyblog.org

Tricks: makes you smile

• SQL injection – reading data by using an expression that returns an ID: select * ... where id =(injectable): collect a set of valid IDs, inject (iwanttoknow & mask){1:id1,2:id2,3:id3}
• TIOCSTI: when root runs untrusted binary via sudo as a local user, it can inject commands run as root
• copy&paste of commands from HTML: visible commands may contain “invisible” text pasted into plain-text; this is browser-dependent
• lazy DNS admin: if local.domain is 127.0.0.1, the same-origin policy can be circumvented
• interesting targets for local file inclusion attacks:
  • /var/log/*, /tmp/sme_session_file, /proc/.../fd/… (used if you don’t know file path), /proc/…/environ (affected by CGI headers), both especially with /proc/self
  • some of that can have controlled content, which turns PHP inclusion into PHP execution

Running your own GSM network

• network authenticates a mobile device, but the device does not authenticate a network
• don’t try this: GSM in licensed spectrum
• network architecture:
  • intelligence in the network, not end nodes
  • GSM: TDMA => data sender/destination identified only by time slot
  • MS = mobile station (phone)
  • BTS = base transciever station – only a transciever, not “intelligent”; L1, parts of L2 – frame scheduling, …; slave to BSC
  • BSC = base station controller: most of decision making, controls BTSs, handles call handover between BSCs
  • MSC = mobile switching center: call switching, “interworking” with ISDN/POTS, inter-BSC call handover
  • HLR/VLR = home/visitor location register
  • BSC< ->BTS interface: A-bis: control E1 line, encoded voice data on other E1 lines (E1 = European ISDN primary rate interface: 32 TDM multiplex channels of 64 kbits)
  • speech/data: 64kb/s split into 4 16kb/s subchannels
  • speech: “full rate” 13kb/s (260b/20ms), “half rate”, “enhanced speech codec”, …
  • “full rate” packeted into 16kb/s (320b/20ms) stream of “TRAU packets”
  • radio link layer: call control, mobility mgmt (roaming, handover, …), radio resoure mgmt, SMS
• Siemens BS-11 microBTS: 2G; documentation under NDA, but 99.9% of A-bis is standard
• IMSI/IMEI skimming:
  • phone will pick strongest network – not home network!
  • can ask it for IMSI/IMEI, then reject them => they connect to their home network
  • => can observe statistics of owner country, phone manufacturer
• “Egypt detection”: GPS is illegal in Egypt
  • => if a phone sees an Egypt BTS, it disables GPS
  • => if a BTS identifies as an Egyptian provider, it disables GPS on phones!
• MITM attack: can get an incoming call – but where do you route it?
  • for a “real” MITM you need very good control of a “mobile phone” component
  • routing through e.g. ISDN fairly easy – but easier to trace back

eVoting after Nedap and Digital Pen

• should be free, fair, general => need to be verifiable, transparent, secret:
  • secret => free, no vote selling
  • auditable => fair and honest
  • transparent => does not rely on authorities to ensure fairness, adds legitimacy
• transparency supposed to be mandatory (OCSE), approaches:
  • Germany: anyboty can observe election and counting (not necessary a citizen, …) – only restricted for safety and public order
  • Austria: parties can nominate 2 election witnesses per polling station
  • UK: parties can nominate witnesses, others can register for observation
• paper voting “white box” – does not do any processing;
• e-voting: processing not observable, input is secret => output unauditable
• reasons for e-voting:
  • cheaper
  • “already spent the money on equipment”
  • saves 1 hour of counting
  • more complex systems (cumulative voting, preferential, …) practical to implement
• fix suggestion: physical copies (paper trail, digital pen …):
  • what triggers recount, who decides what to audit, who has the copies? => fixes auditability, not transparency
  • to ensure correctness, # of audited stations may be very large when results are close (Hesse 2008: difference of ~1 vote / station)
  • what if they don’t match? which one is binding?
  • TEMPEST-proof printers impractical => problems with secrecy
  • printer reliability, vendors object
• => suggest cryptography:
  • voter can verify his vote was correctly counted, but can’t prove his selection to others
  • all ballots have unique ID, all encrypted votes are published, voter can verify his vote is on list
  • does not protect against ballot stuffing
  • does not allow external observers
  • how many voters need to cooperate to prove fraud?
  • if I know somebody won’t check (e.g. by adding a trash and collecting receipts), can I change the vote?
  • can the system be decrypted? by whom?
  • what if vote ID actually identifies something about voter?
  • what if multiple voters receive the same receipt? then there are free IDs for vote stuffing
• ThreeBallot:
  • 3 columns per candidate, mark chosen twice, the others once
  • machine verifies the ballot is valid
  • get copy of 1 column chosen by the voter => each voter can verify 1/3 of their vote is correctly counted, we assume the counter does not know which 1/3 will be verified
  • not coercion free: vote buyer can ask for a specific pattern, then verify the pattern was published
  • serial #
  • checker/copy mechanism is trusted
  • user-unfriendly
• randomized partial checking:
  • permute votes/”connection”/result:
  • for each connection, publish one side of the connection => 50% chance of uncovering a vote flip for each vote => 2**(-n) probability of vote flipping
  • [commitment protocol: can commit to a secret, publish a "verification", then can prove the secret]
• punchscan:
  • individual vote sheets: random # for each candidate on top sheet + holes, random number in different order on bottom sheet => mark both top and bottom sheet, take 1 home, vote with the other – connected by serial #
  • neither sheet allows proving a vote
  • does not prevent coercion: with 2 candidates, can require voting for 1 with only 33% probability of successful opposite vote
• scantegrety 1,2
• bingo voting:
  • prepare a random number for each (voter,candidate), commit to the selection
  • voter selects candidate, trusted RNG generates a random #
  • receipt with fresh random # for chosen candidate, # from committed list for others => can count unused random #s
  • publish results, all receipts, unused dummy votes, randomized proof that ..[sommething]
  • votes can be stolen if a RNG is controlled: can return two identical receipts for two votes with same candidate, then vote in any way instead => have to trust the RNG
  • commitments must be shared, can observe where they were not downloaded…
• risk of insecure implementation
• if later discovered insecure, can’t un-publish records => secrecy risk
• can’t verify a system runs the code, …
• voting authority can publish manipulated data => vote will be considered tampering
• too many different candidates in practice, implementation difficulties: mark 1836 rows once, 93 twice , similar for other cases… => unusable exactly where e-voting is useful
• who actually understands the math and challenge/evaluate a challenge of the system?

An introduction to new stream cipher designs

• stream cipher = something that generates a keystream (a sequence of random-looking data), which is used to XOR the cleartext
  • input = key, IV
• security assumptions: attacker can choose IVs, knows algorithm
• main attacks:
  • distinguishing: distinguishing keystream from true random source
  • recover internal state of the cipher – or even the secret key
• RC4
  • very fast, simple
  • output can be distinguished from random,
  • hard to use correctly,
  • large state, not suitable for HW
  • unspecified IV handling
  • “don’t use, there are better options”
• AES-CTR: “AES in counter mode”:
  • standard, reasonable resource requirements
  • everyone tries to attack it
• rest:
  • lots of bad poprietary ciphers:
  • A5/[12] in GSM: broken
  • E0 in bluetooth: broken
  • MIFARE classic, LEELOQ: broken
  • EU NESSIE: all broken
• eSTREAM: EU-funded research, to create something demonstrably superior to AES at least in 1 aspect
  • 34 submitted ciphers, about half broken
• profile 1: for SW implementation: key >=128b, IV 64 or 128b
  • HC-128: resembles RC4, reuses SHA-256, fast (2-4 cycles/byte, AES has 15-30), very slow for small inputs
    • Rabbit: had patent issues, now public domain; RFC 4503, fast on long streams
    • Salsa20/12: by djb
    • SOSEMANUK: reuses SNOW 2 and SERPENT
• profile 2: for HW implementation in small embedded devices
  • Grain v1: compact, can be unrolled X “tight security margin”
  • MICEKY 2: slow, large
  • Trivium: fast, large state, simple
  • (F-FCSR-H: broken)
• NIST SHA-3 competition:
  • 17/51 in the first round broken…

Analyzing RFID Security

• challenge-response authentication:
  • card->reader: ID, Random_c
  • reader->card: Encrypt(Randomc), Randomr # authenticates reader
  • card->reader: Encrypt(Randomc, Randomr) # authenticates card
• proxy/relay attack:
  • MITM: emulate a reader for a card, and a card for a reader
  • by measuring travel time one can limit attack distance to ~30m, but that’s expensive and not implemented
  • “always possible”
• emulation: spoof “unique” data such as card ID
  • some “authentication” systems only use card ID, do not do any card auth!
• replay: if we can force a known challenge
  • generating random numbers in RFID is rather difficult – no state, no memory
  • Mifare: completely predictable random numbers (known LSFR)
• crypto attacks:
  • brute force, try many keys at once, the same with SAT solvers
  • Mifare: FPGA cluster brute forces key in 50 minutes!
  • rainbow tables: trade off space vs. time: 48 bit (mifare) is very doable; anything below 64 bits possible
  • algebraic attack: describe weak parts as equations, brute-force complex parts, solve the result using a SAT solver (MiniSAT) to get the key [e.g. guess a few bits of the key - most guesses will be unsatisfiable, then we can continue or just solve the equations]
• market overview – insufficient security: Mifare Classic, Hitag2, some Legic, some HID, Atmel CryptoRF, Atmel CryptoMemory
• proposed mitigation for Mifare Classic:
  • signing: strongly authenticate data
  • radio fingerprinting to detect emulation
• #1 enemy of RFID: vandalism (supposedly by people forced to use it?)

DECT

• cordless phones, wireless ISDN access, baby phones, remotely controlled door openers, traffic lights(!); ~30m base stations in Germany
• FP = fixed part, PP = portable part; RFPI = radio FP identity, IPUI = international portable users identity; DSC = DECT standard cipher, DSAA = DECT standard authentication agorithm; UAK = user authentication key (shared between handset and base station)
• DECT: digital, 10 channels in EU, 5 in US, 24 time slots per channel (12 up, 12 down)
• scrambling: “data” xored with a LSFR output; LSFR public
• encryption: both control and data XORed with a DSC stream
• FP is broadcasting network info, scanning for PP activity
• PP: list of carriers, select beset carrier/slot, open connection,…
• sniffing: stations not synchronized, no packet source/destination, don’t know on which channel/slot is used by PP to open connection, frame # must be known for descrambling => ~2GHz CPU required, €1000
  • PCMCIA card ComOnAir: €23, low CPU requirements
• DECT security:
  • phone authentication based on UAK, challenge, FP’s challenge (to handle roaming)
  • network authentication based on UAK, challenge, …
  • hardwired in phone (not chip card)
  • encryption uses phone authentication data + IV
  • all algorithms in DSAA hardwired, secret
  • sometimes no authentication, no encryption at all
  • sometimes network does not authenticate to phone
  • sometimes authentication OK, but no encryption
• passive voice sniffing when no encryption is used: €23 total cost
• voice sniffing when encryption is used:
  • impersonate a base station – most phones won’t abort connection if the base station does not abort!
  • need to know the base station’s and phone’s ID;
• DSAA algorithm: uses for authentication, key generation, UAK generation
  • secret, reverse engineered: A12,A21,A22 simple wrappers around A11,
  • A11: 4 different block cipher invocations
  • “cassable” block cipher:
    • 6 rounds, last does not use key => 5 effective rounds
    • differential attack: with 16 chosen input-output pairs, 2^37 invocations (and other attacks)
• DSC: secret – but parts patented => public … and mostly reverse-engineered
• UAK: 4-digit PIN, depends on RNG, …; some implementations use very low-entropy RNG => impersonate handsets, decrypt calls, …
  • few DECT stacks actually used, equipment manufacturer’s code can be used to identify
  • prepaired phones: can read UAK from EEPROM? most have test contacts in battery case…

Attacking NFC mobile phones

• RFID, modes:
  • reader/writer; most often used
  • card emulation
  • peer-to-peer (two NFC devices)
• range: ~4 cm, data transfer up to 424 kb/s
• usage: touch tag with phone=> launch web browser, initiate voice call, send SMS, store vCard/vCal/note, set alarm, …, launch custom application
• no link security (unecrypted wireless)
• NFC data exchange format:
  • new subformat: SmartPoster = uri with title and optional icon, recommended action (execute, save for later, open for editing), …
• Nokia xxx:
  • reader always active unless phone in standby
  • NFC tag handled by running application, or by phone
  • application can register for specific data types (if not reserved type)
• NFC phones are typically not smart phones => limited SW, attacks mostly based on social engineering
• Mifare classic tag: 720 or 3408 bytes of payload
  • per-sector configurable R/W mode, controlled by 48-bit keys
  • attempts to write to sectors, brute-force keys: 10 keys/s
• Nokia: browser fetches the URL – ignores “action”
• URI spoofing: GUI mixes informational text and control data => can trick the user to open unintended URLs by storing a fake URL in the informational text, then padding it to hide the original URL.
  • URL not displayed in the browser => easy to run a proxy that captures account info; only part displayed => can do …@… (produces a broken HTTP request, but that can be worked around; can not use / in username@, need to use )
  • same for spoofing 0900 phone #
  • sending SMS same, but the SMS URL and text is shown => can be noticed
  • actually documented in the spec!
  • most fixed in recent phones
• application can register for an URI => can intercept all tag read events for URI tags
• use writable tags to install MIDlets (JARs): no security warning on install, only on execution
• fuzzing:
  • need manual moving the tag between writer and reader…
  • phone switches off after 4 crashes in a row
• “survey”:
  • most services don’t require an extra application, all use Mifare Classic 1k
  • Wiener Linien: send a SMS to buy a ticket; tag read-only, but can stick a tag over it to send to other #
  • Selecta vending machine: sending a SMS to pay: can take tag from other machine, copy it and put it on other machines, then wait for a snack paid for by other people
  • OBB-Handy ticket (trains): station encoded into URL => by replacing a tag can track users
  • RMV Handy (Frankfurt): requires application install, NFC is non-essential; use custom record for station ID and name, public signature X signature only protects data, can copy the tag and put it elsewhere; URI for time table only visible if application is not installed
• ConTag tags are not “truly” read only
  • can overwrite data if key B is broken
  • unused sectors left unlocked => can change keys for these sectors, then store my data
• tag attacks: stick an attacker’s tag over the original tag (shield the original off, or “fry” it); tag costs €1.2 in small quantities
• when storing a new value to a tag via a phone, old data is not cleared?
• DoS / discredit the system: write “problematic” content (phone crashers) on tags, stick them around
• Nokia Bluetooth imaging: send selected picture from phone to a Bluetooth device specified in the tag
  • activates Bluetooth if disabled!
  • simple MitM by replacing a tag with my bluetooth MAC, then forwarding the data to original
• Java/Nokia allow quite low-level access, even for talking to smartcards

Why technology sucks

• “technology cannot solve problems created by politicians/accountants/…”
• “technology does not create problems, only make them more urgent”
• “ov-chipkaart”: public transport in Netherlands
  • paper tickets: revenue distribution does not reflect usage, nobody knows how many tickets are left unused, people afraid on the train (fare dodgers?)
  • => chip card, works as an e-ticket: check in on entry, check out when leaving
  • can observe each user traveling; supposedly have to keep records for tax reasons for 7 years => available to prosecutors
• logging of internet accesses…
• “smallmail”: “e-mail replacement”, connecting using TLS over Tor
  • anonymous servers, accounts – using Tor
  • suggestion: use more mailboxes (1 for each “group”) on different servers to make correlation attacks more difficult
• smallsister.org

Predictable RNG in the vulnerable Debian OpenSSL package

• predictable for 2 years
• can brute force:
  • challenge-response auth (server depends on client’s RNG security!):
    • countermeasures: detect weak keys, remove them; Debian’s ssh can reject them automatically
  • MitM: if the server’s cert is weak
    • survey: ~3% of CA-signed certs are weak
    • most browsers don’t check for cert revocaiton (only IE in Vista)
  • DH
    • attacking Apache: each connection has a different state => need to capture all connections in order to recover state
  • DSA: depends on RNG security of all signature operations