Embedded System SecurityEmbedded System SecurityLearning from Banking and Payment IndustryLearning from Banking and Payment Industry

Narudom Roongsiriwong, CISSPNarudom Roongsiriwong, CISSPJuly 19, 2017July 19, 2017

WhoAmI● Lazy Blogger

– Japan, Security, FOSS, Politics, Christian– http://narudomr.blogspot.com

● Information Security since 1995● Embedded System since 2002● Head of IT Security and Solution Architecture,

Kiatnakin Bank PLC (KKP)● Consultant for OWASP Thailand Chapter● Committee Member of Cloud Security Alliance (CSA), Thailand

Chapter● Committee Member of Thailand Banking Sector CERT (TB-CERT)● Consulting Team Member for National e-Payment project ● Contact: narudom@owasp.org

Information Security Fundamental

What is Security? “The quality or state of being secure—to be free

from danger” A successful organization should have multiple

layers of security in place: Physical security Personal security Operations security Communications security Network security Information security

What is Information Security? The protection of information and its critical

elements, including systems and hardware that use, store, and transmit that information

Necessary tools: policy, awareness, training, education, technology

Security Concepts

Security Concepts

Core

Design

Confidentiality Integrity Availibility

Authentication Authorization Accountability

Need to Know Least Privilege Separation of Duties

Defense in Depth Fail Safe / Fail Secure

Economy of Mechanisms

Complete Mediation

Open Design Least Common Mechanisms

Psychological Acceptability Weakest Link Leveraging Existing

Components

Confidentiality-Integrity-Availability (CIA)

To ensure that information and vital services are accessible for use

when required

To ensure the accuracy and completeness of information to protect business processes

To ensure protection against

unauthorized access to or use of

confidential information

Security vs. Usability

Security

Usability

Learning from Payment Industry

Why Learn IoT Security from Payment IndustryIoT systems face the same problems as card payment system faced before● Initial design was for private point to point network

then moved to IP network and later on the Internet● Started with basic security then found the security

flaws and attached more complex security requirements later

● Low security devices from early design are still out there and used in compatible fall-back mode

Payment Ecosystem

Four-Party Model

Simplified Authorization Flow for Card Payment1. The customer make a payment. Enter cardholder data into the merchant’s

payment system (POS, e-commerce website).2. The Merchant sends card data to an acquirer/payment processor who will

route data to through the payments system for processing. For e-commerce, a payment gateway may redirect website to the acquirer.

3. The acquirer/processor sends the data to Payment brand4. Payment brand forwards the data to the issuer. The issuer verifies and

make approval. . For e-commerce, a payment gateway may redirect website to the issuer (ex. Verified by VISA).

Simplified Authorization Flow for Card Payment5. If the issuer agrees to fund the purchase, it will generate an

authorization number and routes back to the card brand.6. Payment brand forwards the authorization code back to the

acquirer/processor.7. The acquirer/processor sends the authorization code back to

the merchant.8. The merchant concludes the sale with the customer.

Smart Payment Cards

Architecture● ISO/IEC 7810 standard size

(normally ID-1) card that has embedded integrated circuit with microprocessor

● Provide– Personal identification– Authentication– Data storage– Application processing

● Design– Contact smart card

(ISO/IEC 7816)– Contactless smart card

(ISO/IEC 14443)– Hybrid

C1–VCC

C2–RST

C3–CLK

C4–

C5–GND

C6–VPP

C7–I/O

C8–

Structure and Packaging

Active Chip Side

Chip Adhesive

Chip

Metal Contacts

Card BodyEncapsulation

SubstrateBond Wire

Hotmelt

CPUCPU

RAMRAM

Test LogicTest Logic

ROMROM

EEPROMEEPROMSerial I/OInterfaceSerial I/OInterface

Security Logic

Security Logic

bus

Inside Smart Card● CPU:

– Microprocessor– Cryptographic co-

processors– Random number generator

● Security Logic: Detecting abnormal condition (e.g. low voltage)

● Serial I/O Interface: Contact to the outside world

● Test Logic: Self-test procedure

CPUCPU

RAMRAM

Test LogicTest Logic

ROMROM

EEPROMEEPROMSerial I/OInterfaceSerial I/OInterface

Security Logic

Security Logic

bus

Inside Smart Card● ROM:

– Card operating system– Self-test procedures– Typically 16 KB

● RAM:– ‘scratch pad’ of the processor– typically 512 bytes

● EEPROM:– Cryptographic keys– Pin code– Biometric template– Balance– Application code– Typically 8 kb

Basic Security FeatureHardware● Closed package● Memory encapsulation● Fuses● Security logic (sensors)● Cryptographic co-

processors and random generator

Software● Decoupling applications

and operating system● Application separation

(Java card)● Restricted file access● Life cycle control● Various cryptographic

algorithms and protocols

Card OSThe two primary types of smart card operating systems are● Fixed File Structure

– Files and permissions are set in advance by the issuer– Seldom used for payment cards

● Dynamic Application– Enables developers to build, test, and deploy different on

card applications securely– Updates and security are able to be downloaded and

dynamically changed– MULTOS and JavaCard are the two main OS standards

JavaCard vs MULTOSJavaCard● A standard, flexible tool

box● A known language and

an easy tool for applet developers in cards

● Requires the addition of Global Platform (or similar) to manage the card and its applets

MULTOS● A turn key system● Comes as a complete

package for cards issuers, with its certification authority, language, tools and personalization process

● Global platform is possible

Global Platform – Card application management and issuance in the card as well as in the back-end

Payment Terminal

What Is A Payment Terminal?● Also known as a point of sale terminal, credit card

terminal, EFTPOS terminal, Electronics Data Capture (EDC)

● A device which interfaces with payment cards to make electronic funds transfers

Payment Terminal Reference Design

Source: Maxim Integrated

Payment Terminal Use Case

Terminal Line Encryption (TLE)

POS Terminal

Acquirer/Processor Network

Credit Card Network

Encrypted

EncryptedEncrypted Plain

Private

PSTN

GPRS/3G

DMZ

TLE

EMVIC Card Specifications for Payment Systems

EMV● A technical standard for smart payment cards and

for payment terminals and automated teller machines (ATM)

● The initiative for EMV was taken by Europay, MasterCard and Visa in the 1990s (now managed by EMVCo)

● Support both ISO/IEC 7816 for contact cards, and standards based on ISO/IEC 14443 for contactless cards (MasterCard Contactless, PayWave, ExpressPay).

EMV Specification● Current version is 4.3● Consist of four books

– Book 1 - Application Independent ICC to Terminal Interface Requirements

– Book 2 - Security and Key Management– Book 3 - Application Specification– Book 4 - Cardholder, Attendant, and Acquirer Interface

Requirements

EMV Basics● Highly configurable tool-kit for payment protocols,

offering a choice between:– 3 Card Authentication Methods: SDA, DDA, and CDA;– 5 Cardholder Verification Methods: none, signature, online

PIN, offline unencrypted PIN, and offline encrypted PIN;– 2 types of transactions: on- and off-line transactions.

● Many of these options are parameterized● 3DES is the major symmetric key algorithm with

128-bit key length (effective 112 bits), AES-128 is optional (since July 2010)

Key Infrastructure● Every card has a unique symmetric key MKAC that it

shares with the issuer, derived from the issuer’s master key MKI

● Using MKAC a session key SKAC can be computed, based on the Application Transaction Counter (ATC) on the card which is increased on every interaction and included as a nonce in security-critical steps protocol steps to prevent replays.

● The issuer has a public-private key pair (PI , SI), and the terminal knows this public key PI.

● Cards that support asymmetric crypto also have a public-private key pair (PIC , SIC) and an associated certificate, signed by the issuer

Key Infrastructure: Authenticity of Data● All EMV cards can provide MACs (Message

Authentication Codes) on messages, using the symmetric keys they share with the issuer.– The issuer can check these MACs to verify authenticity of

the messages, but the terminal cannot.– These MACs are included in the Application Cryptograms

(ACs) that the card provides as evidence that it has take some steps in a transaction.

● Cards that support asymmetric crypto can also digitally sign messages.– Not only the issuer can then check the authenticity of these

messages, but also the terminal.

An EMV Protocol Session1. Initialization: selection of the application on the

smart card and reading of some data;2. Card authentication, by means of SDA, DDA, or CDA;

(optionally)3. Cardholder verification, by means of PIN or

signature; (optionally)4. The actual transaction.5. Issuer-to-card script processing, which allows

issuers to update cards in the field. (optionally)

Initialization● Application selection process (card scheme and

product) between the card and the terminal● Initiate application processing

– The terminal sends the get processing options command to the card with any data elements requested by the card during application selection

– The card responses with Application Interchange Profile (AIP) and Application File Locator (AFL)

● The terminal obtains application data indicate by AFL● The terminal checks card restrictions

– Application version number– Application usage control (This shows whether the card is only

for domestic use, etc.)– Application effective/expiration dates checking

Card Authentication Mechanism (CAM)The AIP tells the terminal which methods the cards supports, and the terminal should then choose the ‘highest’ method that both the card and itself support.● SDA (Static Data Authentication):

– The card provides some digitally signed data (including e.g. the card number and expiry date) to the terminal to authenticate itself.

– However, this does not rule out cloning

● DDA (Dynamic Data Authentication):– DDA cards can do asymmetric crypto and have a public/private key pair, and a

signature of the public key to prove its authenticity via a challenge-response mechanism.

– Even though the terminal can authenticate the card but cannot verify that the subsequent transaction is actually carried out by that card.

● CDA (Combined Data Authentication):– CDA repairs this deficiency of DDA. With CDA the card digitally signs all important

transaction data, not only authenticating the card, but also authenticating the transaction.

1.Get the CA public key from ATM / POS storage2.Use the CA public key to verify the Issuer RSA key in Issuer Certificate3.Use the Issuer RSA key to decrypt the SDA Signature and verify that what was signed is

identical to the read card data

SDA (Static Data Authentication)

DDA/CDA

1.Get the CA public key from ATM / POS storage2.Use the CA public key to verify the Issuer RSA key in Issuer Certificate3.Use the Issuer public key to verify the Card public key in Card Certificate4.Use the Card public key to verify the Signature

Cardholder Verification● The card provides the terminal with its list of

Cardholder Verification Method (CVM) Rules, by a PIN, a handwritten signature, or it can simply not be done.

● If cardholder verification is done by means of a PIN, there are three options:– Online PIN, in which case the bank checks the PIN– Offline plaintext PIN, in which case the chip checks the PIN,

and the PIN is transmitted to the chip in the clear– Offline encrypted PIN, in which case the chip checks the

PIN, and the PIN is encrypted (with public key) before it is sent to the card.

Offline Enciphered PIN Verification

EMV Card Transaction Processing

ARQC – Authorization Request CryptogramARPC – Authorization Response Cryptogram

Known attacks and weaknesses of EMV● Mag-stripe cloning using chip information● Reliance of symmetric keys for authenticity

– Not provide true non-repudiation– The terminal can not check the authenticity of cryptograms

● Cloning SDA cards● Faking offline transactions with DDA cards● Faking offline PIN verification● Rollback to unencrypted PIN● Bad random-number generators

Lesson Learned from Card Payment Ecosystem● Security is not only about technology but also process

and risk management (especially on risk appetite)● In multiple party environment, the maximum security

depends on the weakest implementation of the corresponding parties

● All core security concepts are fully implement– Confidentiality: encryption on data transmission– Integrity: message authentication code, certificates– Availability: offline processing– Authentication: card authentication, cardholder verification– Authorization: card issuer authorization– Accountability: message authentication code, transaction log

at payment terminal and issuer

Secure IoT Devices That We Design

Types of IoT Classified by Communication● Client Type

– Most of implementation– e.g. payment terminal, IP Camera (call back to server),

Smart Cars

● Server Type– e.g. IP Camera (built-in web interface)

● Peer-to-Peer or Mesh

Typical IoT Infrastructure

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Configuration App

Callback and wait for commands Remote control

RemoteControl App

Configure or Update Firmware

Configure

Typical Attack: Fake Control Server

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Callback and wait for commandsRemote control

RemoteControl AppFake Control Server

Typical Attack: Attack on Device Open Ports

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Callback and wait for commands Remote control

RemoteControl App

Typical Attack: Attack on Server Open Ports

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Callback and wait for commands Remote control

RemoteControl App

Attack

Typical Attack: Steal Credential

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Callback and wait for commands Remote control

RemoteControl App

Typical Attack:Inject Bad Configuration or Firmware

Control Server

IoT Device

Private or PublicInternet

PublicInternet

Callback and wait for commands Remote control

RemoteControl App

Inject Bad Configuration or Firmware

Inject Bad Configuration

Typical Attack: Sniff Data on Private Network

IoT Device

PrivateInternet

PublicInternet

Callback and wait for commands Remote control

RemoteControl App

Control Server

OWASP Top 10 IoT Vulnerabilities 2014I1 Insecure Web InterfaceI2 Insufficient Authentication/AuthorizationI3 Insecure Network ServicesI4 Lack of Transport Encryption/Integrity VerificationI5 Privacy ConcernsI6 Insecure Cloud InterfaceI7 Insecure Mobile InterfaceI8 Insufficient Security ConfigurabilityI9 Insecure Software/FirmwareI10 Poor Physical Security

Secure IoT Devices That We Use

Mirai Malware● Malware that turns networked devices running Linux into Malware that turns networked devices running Linux into

remotely controlled "bots" that can be used as part of a remotely controlled "bots" that can be used as part of a botnet in large-scale network attacksbotnet in large-scale network attacks

● Primarily targets online consumer devices such as IP cameras Primarily targets online consumer devices such as IP cameras and home routers using a table of more than 60 common and home routers using a table of more than 60 common factory default usernames and passwords, and logs into them factory default usernames and passwords, and logs into them to infect them with the Mirai malwareto infect them with the Mirai malware

● First found in August 2016First found in August 2016● Use in DDoS attacksUse in DDoS attacks

– 20 September 2016 on the Krebs on Security site which reached 620 20 September 2016 on the Krebs on Security site which reached 620 Gbit/s and 1 Tbit/s attack on French web host OVHGbit/s and 1 Tbit/s attack on French web host OVH

– 21 October 2016 multiple major DDoS attacks in DNS services of DNS 21 October 2016 multiple major DDoS attacks in DNS services of DNS service provider Dynservice provider Dyn

– November 2016 attacks on Liberia's Internet infrastructureNovember 2016 attacks on Liberia's Internet infrastructure

● The source code for Mirai has been published in hacker forums The source code for Mirai has been published in hacker forums as open-sourceas open-source

What Can We Learn from Mirai Attacks?● Do not use default passwords for all default

usernames● If possible, do not allow configuration interface

from Internet side● If the IoT devices are used only in the organization,

do not expose to the public Internet● If there is a need to use from the Internet, open

only necessary ports and use non-default ports where possible