SRED Requirements
PCI SSC security programs
PCI PTS
security program
PCI PA-DSS
security program
IP
PCI PTS POI Open PCI DSS security
Protocols program
PCI PTS POI
Secure Reading and Exchange of Data
/ 22
2
Point Of Interaction devices (SRED)
MSR CTLS reader
PIN pads
OEM Secure Card Reader
Secure Card Reader
/ 22
3
Security objectives for SRED (2)
Assets protected by the SRED requirements:
Primary Assets (Cardholder (CHD) Data)
PAN (Primary Account Number)
Optionally: Cardholder Name, Card expiration date, service code etc.
Secondary Assets
CHD-related cryptographic Keys
Salt used to create surrogate PANs
Firmware
What about the PIN?
PIN is cover in module 1 - Core
4
Primary Assets (1)
PAN (Primary Account Number)
Usually 16 digits
Exception : American Express (uses 15 digits)
Maximum length : 19 digits
Where is it stored?
Track 1 and Track 2 data field of the smartcard
Why do we care?
By only knowing the PAN an attacker can perform card-not-present
online purchases (in certain countries e.g. USA)
Also is some cases the PAN can be entered manually in the POI
Conclusion:
PAN is (equally to PIN) important and it should be protected
5
Primary Assets (2)
Expiration date
Cardholder’s name
Cardholder’s info
CVV (Card Verification Value)
Security mechanism to make the life of the attacker more difficult but still
some attacks are feasible
Service Code
Indicates if card is EMV enabled or not
Why do we care?
As explained in the previous slide these values along with the PAN are
required to perform a successful card-not-present attack.
6
PED attack techniques
Secondary Assets (1)
Cardholder related cryptographic KEYS
Secret (symmetric) keys
Private and/or public keys
Why do se care?
Because they are keys
Integrity of the keys stored
Confidentiality of the stored keys
/ 22
7
Secondary Assets (2)
Salt used to create surrogate PANs
Surrogate PANs?
Instead of using the actual PAN value the terminal uses the hash of the PAN.
Salt?
Hash(PAN) scheme is vulnerable to dictionary or brute-force attacks.
Hash(PAN||salt) where salt is a random value is more secure.
Firmware
Any code within the device that provides security protections needed to
comply with the PCI requirements.
Properties to be protected:
Integrity
Authenticity
8
Visual Mapping of the assets
Keypad USB
Masked PAN
Hashed PAN
Encrypted PAN
RS232
IC Card Reader
TCP/IP
Magnetic Stripe
Reader
…
CTLS A/D
Plain PAN
Authenticated
Application
Secure module
Tamper responsive unit
9
Visual Mapping of the assets
Keypad USB
MCU
Masked PAN
Hashed PAN
Tamper el. Encrypted PAN
RS232
IC Card Reader
Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS
Plain PAN
Boot load Authenticated
Application
Secure module
Tamper responsive unit
10
Visual Mapping of the assets
Keypad USB Primary
MCU
Masked PAN
Assets
Hashed PAN
Tamper el. Encrypted PAN
RS232
IC Card Reader
Sec. keys
Pub keys TCP/IP Secondary
Assets
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS
Plain PAN
Boot load Authenticated
Application
Secure module
Tamper responsive unit
11
Visual Mapping of the assets
SALT
APPLICATIONS
Keypad USB
MCU
Masked PAN
Tamper el.
Hashed PAN PAN
Encrypted PAN
RS232
IC Card Reader
Sec. keys FIRMWARE
Pub keys TCP/IP
KEY MANAGEMENT
Magnetic Stripe W. list Salt
Reader AND ENCRYPTION
…
Firmware
CTLS A/D OS
Plain PAN
Boot load Authenticated
Application
Secure module
Tamper responsive unit
12
Card Holder Data through the device
Entering the device
Keypad USB
MCU
Tamper el. RS232
IC Card
CHD Reader
Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
13
Card Holder Data through the device
Delivering to the Application
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader
Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS CHD
Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
14
Card Holder Data through the device
Output: Encrypted
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
Enc.
CTLS A/D OS CHD
CHD Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
15
Card Holder Data through the device
Output: Hashed
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
Hashed
CTLS A/D OS CHD
CHD
Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
16
Card Holder Data through the device
Output: Truncated
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
Trun.
CTLS A/D OS CHD
CHD
Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
17
Card Holder Data through the device
Output: Plaintext
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS CHD
Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
18
Card Holder Data through the device
Final cleaning
Keypad USB
MCU
Tamper el. RS232
IC Card
Reader
Sec. keys
Pub keys TCP/IP
Magnetic Stripe W. list Salt
Reader
…
Firmware
CTLS A/D OS CHD
Authenticated
Boot load Application
Secure module
Tamper responsive unit
/ 22
19
SRED requirements: One by One
20
K1 – Account Data Processing
Goal: minimize risk of Account Data compromise;
Account data must be:
Encrypted as soon as possible;
Processed securely in tamper responsive protected zone;
K1.1 – Account Data Protection
Goal: Protect all account data upon entry;
Attack resistance offered by the device (16/8);
Interfaces themselves must offer A9/D1 protection levels:
MSR (18/9); ICCR (20/9);
All Card Holder Data (CHD) interfaces must be assessed:
MSR, ICCR, Keypad, CTLS (from point of digitization)
21
K1.2 – Independent Security Mechanisms
Goal: Failure of a single security mechanisms does not compromise the device
Security must be implemented using at least 2 independent mechanisms
22
K2 – Account Data Protection - Integration
Goal: Logical/Physical integration must not open new attack paths to the account data
Not applicable for PEDs with an integrated ICC reader
For card readers that are intended to be integrated into a POI;
Guidance documentation must be provided to the integrators,
Potential vulnerabilities:
Skimmer;
ICCR external bug;
Substitution;
Access to CHD during maintenance
23
K3 – Determining Keys Analysis
Goal: Test the protection of CHD related keys against:
physical penetration;
side channel leakage;
Attack resistance required (26/13);
In scope:
Logical protections and counter measures;
Cryptographic algorithms;
Location of plain text key storage;
Side channel analysis experiments;
24
K3.1 – Public Key Protection
Goal: Public keys must be protected against unauthorized modification/substitution
Attack resistance required (26/13);
Their protection must be based on one of the following methods:
Plaintext Public keys can be stored:
within a certificate
within a secure cryptographic device
Alternatively, they can also be stored:
with a MAC created using a ISO 16609 algorithm
Encrypted
25
K4 – Encryption Mechanisms
Goal: Account data must be encrypted using ANSI X9 / ISO-approved algorithms
Encryption algorithms should use ANSI/ISO approved modes;
Non-standard mode are allowed, but require:
Extra assessment;
Independent expert approval;
Minimum key sizes are enforced
See “Appendix D: Minimum and Equivalent Key Sizes and Strengths for Approved
Algorithms “ of PCI PTS POI DTRs v4.1
SRED particularity: “Double length TDES keys are not permitted for SRED use in Fixed key
or Master key/Session key implementations.”
Encryption of account data can be disabled by disabling SRED functionality
26
Clarification:
Enabling/Disabling SRED functionality
IF the device allows enabling/disabling SRED functionality:
The change of mode of operation is considered a Sensitive Service
The change must:
require explicit authentication
be documented
When SRED functionality is enabled:
The firmware revision number must change to reflect it
The device must provide visual indication of the SRED enablement
27
Question Time!
DTR K4 Encryption Mechanisms
Can a device meet SRED requirements without encrypting account data?
Short answer:
No
Long Answer, from PTS POI Technical FAQs v4 June 2015:
No. Compliance with K4 is mandatory for any device to be approved
against SRED and have SRED listed as functionality provided.
28
K5 – Remote Key Distribution
If Remote key distribution is used:
The device must support mutual authentication with the key-distribution
host
Goal: Protect the remote key distribution mechanism
Mutual authentication:
PKI ! public/private key pairs;
Symmetric ! Unique key sets;
In any case, conform to ISO/IEC 9798 guidelines
29
K6 – Data Origin Authentication
Goal: The device must support data-origin authentication of encrypted messages
Required to be supported; Optional to be used;
Provide means to authenticate security relevant data:
Digital signatures:
Symmetric ! DES-MAC, etc.
In any case, conform to ISO/IEC 19772:2009
30
K7 – Unique Secret and Private Keys Per Device
Secret and private keys supporting account data encryption are unique per device
Standard key management requirement:
Any Private Key must be unique;
Any symmetric key must be unique;
What method is used to ensure that this is the case?
Goal: the compromise of a key from a single terminal does not affect other terminals
31
K8 – Encryption/Decryption of Arbitrary Data Within a
Device
Identical to B13, but related to account-data encrypting keys
Goal: ensure that keys are only used for its intended use.
Examples:
Account data keys, PIN-encryption keys, Key-encryption keys must have different
values
Key-encryption keys cannot be used to encrypt account data
Account data keys cannot be used to encrypt keys
32
K9 – Remote Access
If the device can be accessed remotely for administration purposes:
All access attempts must be cryptographically authenticated or rejected
Goal: Protect the device against unauthorized remote access
This requirement does not cover:
Application loading
Firmware/Application/Configuration updates
If the administration activity involves sensitive data processing:
A secure session must be established;
33
K10 – Firmware Certification
Identical to B3;
Goal: The firmware and any changes thereafter have been inspected and reviewed
following a documented and auditable process by the vendor.
K11.1 – Software Authenticity
Identical to B4.1;
Goal: The firmware must authenticate all applications loaded onto the device.
Applications or configuration updates, if supported, must be cryptographically
authenticated by the device, or rejected and deleted.
34
K11.2 – Software Guidance
Application developer guidance for secure coding must cover:
Logical anomalies (consistent with B2)
Secure buffer clearing (consistent with B6)
Particularly: Account data is not retained any longer, or used more often, than
strictly necessary
Goal: clear security guidance is provided to application developers
Not applicable for devices not allowing application installation;
35
K12 – Firmware Updates
Identical to B4;
Goal: If the device allows firmware updates, they must be cryptographically
authenticated by the device, or rejected and deleted.
K13 – Logical Anomalies
Identical to B2;
Goal: The device functionality must not be influenced by logical anomalies.
36
K14 – Open Protocols and Services
If the device is capable of communication over an IP network or uses a public domain
protocol;
Then DTR Module 3: Open Protocols Requirements shall be met
F – Disc. & Def. of
G - Vulnerability H - Vendor I - Operational
Protocols and
Analysis Guidance Testing
interfaces
F1 Identification of G1 Vendor Vulnerability H1 Security Guidance I1 Use of Secure
Interfaces Assessment for the Protocols Protocols
Procedures and Interfaces I2 SP to Provide Data
G2 Vulnerability H2 Default Confidentiality
Assessment of all Configuration of I3 SP to Provide Data
Interfaces the Interfaces Integrity
G3 Vulnerability H3 Key Management I4 SP to Provide
Disclosure Security Guidance Mutual
Authentication
I5 SP to Provide
Exception
Handling and
Replay Detection
I6 Session
Management
37
K15 – Output of Clear text Account Data
Goal: When operating in encrypting mode, no mechanism allows the outputting of
clear-text account data.
Two modes are allowed:
Non-encryption mode: allows sensitive data export in plain-text
SRED functionality is disabled
Encrypting mode: prevent sensitive data export in plain-text:
Encipher CHD;
Truncate CHD; (ddddddxxxxxxdddd)
Hash CHD (tokenization, with salt)
When in Encrypting mode
White-lists can be used to exclude card data from mandatory encryption:
They must be cryptographically authenticated, either:
Before use
Before instantiation
38
K15.1 – Protection of Clear-text Data
Goal: When operating in encrypting mode, clear-text account data is only provided to
authenticated applications within the device.
Scope:
Which data is provided to authenticated applications?
E.g. Must NOT release cryptographic keys in plaintext to applications
How are the applications authenticated?
39
K15.2 – Clearing Of Internal Buffers
Similar to B6, but focused on CHD;
Goal: Account data (encrypted or in clear-text) is not retained any longer, or used more
often, than strictly necessary.
Active erasure of plain CHD must be enforced upon;
Time-out condition;
Completion transaction;
The vendor must define:
“Time-out” and “completion of transaction” conditions
The active erasure method
And defend/prove its robustness
40
K16 – Surrogate PAN Values
If surrogate PAN is supported:
Goal: It is not possible to determine the original PAN knowing only the surrogate PAN
Scope of the requirement:
Method for creation;
Involved cryptographic algorithms and keys
41
K16.1 – Salt Generation
If surrogate PAN is supported, and hash functions are used to generate it
Goal: The input to the hash function uses a 64 bit long salt at least.
Scope of the requirement:
Uniqueness of the salt per: Salt generated outside the device.
merchant Loaded through a sensitive service
device
transaction / group of transactions Salt must be generated by the device
Method of creation;
Length >= 64 bit;
K16.2 – Salt Storage
If surrogate PAN is supported, and hash functions are used to generate it
Goal: Salt values are kept secret and appropriately protected
Scope of the requirement:
Where is the salt stored?
How is it protected?
Protection level (16/8);
42
K17 – Key Management
Identical to B11;
Goal: Key management in the device conforms to industry-agreed standards of
security and interoperability
Conform to ISO 11569 and/or ANSI X9.24.
Supports ANSI TR-31 or equivalent key derivation for TDES key bundles.
43
(Unfair) Question Time!
DTR K17 Key Management
For loading AES keys, which of these methods are allowed / not allowed?
a) Loaded encrypted using a RSA-2048 bits key
b) Loaded encrypted with a TDES key
c) Loaded encrypted by another AES key of equal strength
d) Manually injected as a single component
e) Internally generated using a RNG compliant with B9
Hint: Strength equivalence table for key-encipherment keys from PCI PTS POI DTRs v4.1
44
(Unfair) Answer Time!
DTR K17 Key Management
For loading AES keys, which of these methods are allowed / not allowed?
a) Loaded encrypted using a RSA-2048 bits key
b) Loaded encrypted with a TDES key
c) Loaded encrypted by another AES key of equal strength
d) Manually injected as a single component
e) Internally generated using a RNG compliant with B9
Hint: Strength equivalence table for key-encipherment keys from PCI PTS POI DTRs v4.1
45
K18 – Exhaustive PAN Determination
Goal: Prevent or deter the use of a device for exhaustive PAN determination.
Similar to B10, but
Focused on PAN instead of PIN;
Does not enforce a hard limit on the rate of transactions
Examples of accepted techniques:
Prevent: Unique key per transaction;
Deter: Limit the rate at which the device will encrypt PANs
46
K19 – Robustness Under Changing Environmental
and Operational Conditions
Identical to A3;
Goal: Alteration of environmental/operational conditions do not compromise the
security of the device
K20 – Application separation
Identical to B17;
Goal: If multiple applications are supported, it is not possible that they interfere with
each other or the firmware
K21 – Minimal Configuration
Identical to B18;
Goal: The OS of the device is configured securely, and contains only the software
necessary for its intended operation
47
K22 – Protection of Sensitive Services
Identical to B7;
Goal: Access to sensitive services requires authentication
K23 – Sensitive Services Limits
Identical to B8;
Goal: Sensitive services have a limit on the number of actions that can be performed
and a time limit before being forced to return to normal mode
Requirements related to sensitive services:
K22 – Protection of Sensitive Services
K23 – Sensitive Service Limits
If SRED functionality can be enabled/disabled
K4 – Encryption Mechanisms
K15 – Output of Clear-text Account Data
If Salt is generated by the merchant, and has to be loaded in the device
K16.1 – Salt Generation
48
SRED requirements
49
Contact
Brightsight
Payment Terminal Security group
Delftechpark 1
2628XJ Delft
Tel: +31 15 269 2522
Fax: +31 15 269 2555
www.brightsight.com
[email protected] 50
51
