Nowaday, embedded systems are widely used and connected to networks, especially the Internet. This become the Internet of Things (IoT) era. When a device is on the Internet, it may be attacked or intentionally used by an unauthorized persons. How can we make IoT devices secure under the limited resources? This presentation will explain the lesson learned from banking and card payment industry how the embedded systems process financial transaction reliably and securely.

1. Embedded System SecurityEmbedded System Security
Learning from Banking and Payment IndustryLearning from Banking and Payment Industry
Narudom Roongsiriwong, CISSPNarudom Roongsiriwong, CISSP
July 19, 2017July 19, 2017

2. 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

3. Information Security Fundamental

4. 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

5. 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

6. 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

7. 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

8. Security vs. Usability
Security
Usability

9. Learning from Payment Industry

10. Why Learn IoT Security from Payment Industry
IoT 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

11. Payment Ecosystem
Four-Party Model

12. Simplified Authorization Flow for Card Payment
1. 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 brand
4. 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).

13. Simplified Authorization Flow for Card Payment
5. 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.

14. Smart Payment Cards

15. 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–

16. Structure and Packaging
Active Chip Side
Chip Adhesive
Chip
Metal Contacts
Card Body
Encapsulation
Substrate
Bond Wire
Hotmelt

17. CPUCPU
RAMRAM
Test LogicTest Logic
ROMROM
EEPROMEEPROM
Serial I/O
Interface
Serial I/O
Interface
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

18. CPUCPU
RAMRAM
Test LogicTest Logic
ROMROM
EEPROMEEPROM
Serial I/O
Interface
Serial I/O
Interface
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

19. Basic Security Feature
Hardware
● 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

20. Card OS
The 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

21. JavaCard vs MULTOS
JavaCard
● 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

22. Payment Terminal

23. 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

24. Payment Terminal Reference Design
Source: Maxim Integrated

25. Payment Terminal Use Case

26. Terminal Line Encryption (TLE)
POS Terminal
Acquirer/Processor Network
Credit Card
Network
Encrypted
Encrypted
Encrypted Plain
Private
PSTN
GPRS/3G
DMZ
TLE

27. EMV
IC Card Specifications for Payment Systems

28. 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).

29. 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

30. 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)

31. 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

32. 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.

33. An EMV Protocol Session
1.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)

34. 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

35. 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.

36. 1.Get the CA public key from ATM / POS storage
2.Use the CA public key to verify the Issuer RSA key in Issuer Certificate
3.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)

37. DDA/CDA
1.Get the CA public key from ATM / POS storage
2.Use the CA public key to verify the Issuer RSA key in Issuer Certificate
3.Use the Issuer public key to verify the Card public key in Card Certificate
4.Use the Card public key to verify the Signature

38. 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.

39. Offline Enciphered PIN Verification

40. EMV Card Transaction Processing
ARQC – Authorization Request Cryptogram
ARPC – Authorization Response Cryptogram

41. 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

42. 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

43. Secure IoT Devices That We Design

44. 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

45. Typical IoT Infrastructure
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Configuration App
Callback and wait for commands Remote control
Remote
Control App
Configure or
Update Firmware
Configure

46. Typical Attack: Fake Control Server
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Callback and wait for commands
Remote control
Remote
Control AppFake Control Server

47. Typical Attack: Attack on Device Open Ports
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Callback and wait for commands Remote control
Remote
Control App

48. Typical Attack: Attack on Server Open Ports
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Callback and wait for commands Remote control
Remote
Control App
Attack

49. Typical Attack: Steal Credential
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Callback and wait for commands Remote control
Remote
Control App

50. Typical Attack:
Inject Bad Configuration or Firmware
Control Server
IoT Device
Private or Public
Internet
Public
Internet
Callback and wait for commands Remote control
Remote
Control App
Inject Bad
Configuration
or Firmware
Inject Bad
Configuration

51. Typical Attack: Sniff Data on Private Network
IoT Device
Private
Internet
Public
Internet
Callback and wait for commands Remote control
Remote
Control App
Control Server

52. OWASP Top 10 IoT Vulnerabilities 2014
I1 Insecure Web Interface
I2 Insufficient Authentication/Authorization
I3 Insecure Network Services
I4 Lack of Transport Encryption/Integrity Verification
I5 Privacy Concerns
I6 Insecure Cloud Interface
I7 Insecure Mobile Interface
I8 Insufficient Security Configurability
I9 Insecure Software/Firmware
I10 Poor Physical Security

63. Secure IoT Devices That We Use

64. Mirai Malware
● Malware that turns networked devices running Linux intoMalware that turns networked devices running Linux into
remotely controlled "bots" that can be used as part of aremotely 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 camerasPrimarily targets online consumer devices such as IP cameras
and home routers using a table of more than 60 commonand home routers using a table of more than 60 common
factory default usernames and passwords, and logs into themfactory 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 62020 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 DNS21 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 forumsThe source code for Mirai has been published in hacker forums
as open-sourceas open-source

65. 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