Attacking RFID System [Lukas Grunwald] pdf

(1)

Attacking RFID

Systems

Exploiting ID and ticketing

applications

(2)

Agenda

z

What is RFID?

z

How to exploit and attack RFID systems

z

Attacks against the middleware

z

Reader-emulation, soft-tags

z

Unexpected risk middleware

z

New ways to exploit the system

(3)

What is RFID?

z

Radio Frequency Identification (RFID)

z Wireless transmission of information between

transponder and reader without visibility

z Bidirectional transfer (read and write)

z Transponder (tag) can be attached, embedded or

implanted

z Automatic correlation between object and saved

(4)

Generic Terms

z RFID is often used as generic term for complete

infrastructures.

z A transponder (aka RFID-chip, -tag, -label, wireless label

or simply chip)

z A reader (in fact most of them can write to the tag too)

z Some middleware, which connects the reader to a server

z Some communication infrastructure

z Integration with server farms, data warehouses, services

(5)

Variants

Different types of RFID transponders

EM-field EM-field

E-field, magnetic field

860-956 MHz (UHF) 2.4 GHz (Microwave) 5.8 GHz (Microwave) 13.56 MHz, 125-135kHz 13.56 MHz, 125-134.2kHz ISO 18000-xx ISO 15693

ISO 14443 A+B

Up to 500 meter <= 5meter

<= 15 centimeter

Long range Mid range

(6)

Transponders

z

There are different kinds of transponders:

z Only transmitting a unique ID (serial-number)

z Only passive

z Identification

z Tracking (Fast-track)

(7)

Transponders

z

There are different types of transponders:

z Storage of Data / Metadata R/W WORM

z Most passive, some active

z EPC

z Smart Labels

z Most use clear text communication, some are with

(8)

Transponders

z

There are different types of transponders:

z Act as Smart Card Interface

z Most active, some passive

z Biometric Passport (ICAO - MRTD)

z Access Control System (Mifare DESFire)

(9)

Generic Attacks

z

Sniffing of the communication between

transponder and reader

z Counterfeiting of the communication

z Obtaining UID, user data and meta data z Basic attack on structures and tags

(10)

Generic Attacks

z

Counterfeiting the identity of the reader and

unauthorized writing to the tag

z Change of UID via manipulation of the

administrative block

z Declare false identity

z UID must be readable in clear text

(11)

Generic Attacks

z

Manipulation of data stored on the

transponder

z Manipulation of data

z Manipulation of metadata z Swap of objects

(12)

Generic Attacks

z

Deactivation of the transponder

(13)

Generic Attacks

z Attack the structures in the middleware and

backends, manipulation of data structures.

z Injection of malware into the backend and middleware

systems

z E.g. database worms

z Manipulation of backend systems

(14)

Generic Attacks

z

Jamming of the RFID frequencies

z Use of “out-of-the-box” police jammer (broadband

jamming transmitter)

z Attack against anti-collision (RSA attack) z Prevent reading of the tag

z Simple denial of service attack against the RFID

System

(15)

Encrypted RFID

z

MIFARE are the most used RFID

transponders featuring encryption

z Technology is owned by Philips Austria GmbH z Technology is based on

z ISO 14443

(16)

MIFARE Tags

z

MIFARE Standard

z Proprietary high-level protocol

z Philips proprietary security protocol for

authentication and ciphering

(17)

MIFARE Tags

z

MIFARE Pro, ProX, and SmartMX

z Fully comply to ISO 14443-4 standard

z The different types of tags offer memory protected

by two different keys (A and B)

z Each sector could be protected with one of these

(18)

Brute Force the Tag

z 2^6^8 bit for the keyspace

z 25 ms per try with a brute force perl script using

Linux and a self written driver

z Using one RFID reader

(19)

Brute Force the Tag

z 2^6^8 bit for the keyspace

z 25 ms per try with a brute force perl script using

Linux and a self written driver

z Using 1.000 RFID readers

(20)

MIFARE Sector Keys

z Philips puts all information under NDA

z We are not interested to sign an NDA

z Extract information from RFID software via „UNIX

strings“

z Google helps a lot, Google desktop search is very

popular among smartcard developers´ PCs ;-)

(21)

(22)

Default Keys

z

Found the following default keys:

z Key A A0 A1 A2 A3 A4 A5 z Key A FF FF FF FF FF FF z Key B B0 B1 B2 B3 B4 B5 z Key B FF FF FF FF FF FF

(23)

MAD

z

Additional found the Mifare Application

Directory.

z

This PDF that shows how MIFARE are

specifying the type of use of one of the

(24)

Example Layouts

z In the datasheets and „googled“ documentation

are a lot of examples.

z These examples include different keys and tag /

memory layout and data structure for:

z Ticketing

z Access Control

(25)

Software developers are

lazy

z

Checking a couple of cards shows that more

than 75% use one of these default keys!

z

It compiles let's ship it !

z

The programmers not only use the example

(26)

Attack the Tag

z

Directory attacks are possible with found

default and example keys

z Variations of the directory are always possible

z

„Smart“ brute-force attack to the tag are

possible

(27)

Attacks to the Backend

z

The memory of a ISO 15693 tag acts like a

normal storage

z

RFDump (Black Hat 2004) could help to

manipulate data like with a hex-editor

(28)

Preventing security

functions

z

If the tag is „read only“ read it with RFDump

and write the manipulated data to an empty

one

z

Checksum, some implementations use the

UID (Unique ID) as mirror block in the UD,

both must be changed

z

If the block is encrypted, the Sector Key must

(29)

The RFID Supply chain

Lifecycle Management Point of Sales

Customer Care

Distribution Production

(30)

Break into the Systems

Event Manager

Reader control InformationServer (Middleware)

ERP

.... CRP

(31)

Problem Memory Size

Adr Memory

0x100000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x200000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x300000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x400000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x500000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x600000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x700000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x800000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0x900000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xa00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xb00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xd00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xe00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0xf 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

(32)

Representation to the

Backend

z

Looks like unlimited space on the tag

z E.g. RFDump uses a tag database to avoid

reading over the boundary

z

Normally reading is event-driven

z Reading up to the EOF

z Input is unchecked in all implementations we have

(33)

Tag DoS with C-Strings

Adr Memory

0x1 68547369 69202073 6e616520 6178706d 656c6f20 20662061 616d696e 75706100

0x2 FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xa FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xb FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xc FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xd FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xe FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

0xf FFFFFFF FFFFFFF FFFFFFF FFFFFFF FFFFFFFF FFFFFFF FFFFFFF FFFFFFF

(34)

Tag DoS with XML

Add

r Memory in ASCII

0x1<rfiduid:ID>urn:epc:1:4.16.36</rfuid:ID> 0x2<rfidcore:Observation><rfidcore:DateTime> 0x3<rfidcore:DateTime>2002-11-06T13:04:34-06:00 0x4</pmlcore:DateTime> 0x5 0x6 Mass reading Add

r Memory in ASCII

0x1<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID> 0x2<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID> 0x3<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID> 0x4<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID> 0x5<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID> 0x6<rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID><rfiduid:ID>

(35)

Soft-Tags

z

Emulation of RFID-Tag and/or reader

z

Serial-Emulation of any ISO 15693 tag

z

Useful for testing backend and middleware

z

Reads „backup“ from real tags

z

Manipulation of any UID, User Data or

(36)

ePassports

This image is a work of a United States Department of Homeland Security employee, taken or made during the course of an employee's official duties.

(37)

MRTD

z Machine Readable Travel Document aka Electronic

Passports (ePassports)

z Specifications by ICAO

z (International Civil Aviation Organization)

(38)

ePass from Germany

z RFID tag embedded into the cover

(39)

MRTD

z

Store passport data and biometric information

on an RFID transponder

z Alternative storage methods like 2D barcodes

also covered

z Common standard for interoperability

(40)

2D Code and MRZ

(41)

MRTD Data-Layout

z LDS (Logical Data Structure)

z Data is stored in DG (Data Groups)

z DG1: MRZ information (mandatory)

z DG2: Portrait Image + Biometric template (mandatory)

z DG3-4: fingerprints, iris image (optional)

z EF.SOD: Security Object Data (cryptographic

signatures)

z EF.COM: Lists with Data Groups Exist

z Data is stored in BER-encoded ASN.1

z DG2-DG4 uses CBEFF for encoding

(42)

MRTD Security Features

z Random UID for each activation

z Normally all ISO 14443 transponders have a fixed unique

serial number

z The UID is used for the anti collision

z Prevent tracking of owner without access control

z Problem: ICAO MRTD specs don't require unique serial

number

(43)

Passive Authentication

z This method is mandatory for all passports

z Method of proof that the passport files are signed by issuing

country

z Inspection system to verify the hash of DG's

z EF.SOD contains individual signatures for each DG

z EF.SOD itself is signed

z Document Signer Public Key from PKD / bilateral channels

z Document Signer Public Key can be stored on the passport

(44)

Signed Data

EF.DG2 EF.DG3 EF.COM EF.DG1

HASH over

Data HASH overData

HASH over HASH HASH Signed by

(45)

Basic Access Control

z Permits access to the data after the inspection systems are

authorized

z Authorization through the Machine Readable Zone (MRZ)

z Nine digit document number

z _{In many countries: issuing authority + incrementing number}

z Six digit date of birth

z Can be guessed or assumed to be a valid date

z _{Six digit expiry date}

z 16 most significant bytes of SHA1-hash over MRZ_info are 3DES

(46)

Extended Access Control

z

Optional method

z

Should prevent the unauthorized access to

biometric data

z Not internationally standardized z Implemented by individual issuers

z Only shared with those countries that are allowed

(47)

PKI Integration

z

X.509 Certificates

z Every issuer operates a self controlled CA z Signer keys are derived from CA root

z Public keys are distributed via ICAO PKD z Everyone can verify

z Certificate revocation list (CRL) not planned yet

(48)

Cloning of passports

z Dual Interface Tags could act as MRTD Tag

z Data could be retrieved from an issued passport

z Personalization is possible via Smartcard Shell or

other tools.

(49)

Chaos of Standarts

z TLV and ASN.1 not correctly implemented

z Redundant meta formats for biometric data

z If sign-key gets lost, the whole country is doomed

z First the data must be parsed, then it can be verified

z Design was made by politics and not by IT Security

experts

(50)

Security Issues

z

UID could be changed from the tag

z

Passport-tag could act as Access-Control

tag, if only UID is used, this tag could act as

any access tag

z

Manipulated DGs could crash the reader /

(51)