From the education session "Hard Codes to Crack: Tokenization, Encryption-at-Swipe and Friends" at the HITEC 2012 conference. Provides insight into what to consider when purchasing and implementing a tokenization or point-to-point encryption solution to protect payment data, with a particular focus on the hotel or lodging industry.

1. Geoff Krieg
VP of Product Management, Merchant Link

2. A Flexible, Layered Approach
to Security
• Acquirer Neutral – Enable merchants
and franchisees to process via
the acquirer they prefer
• Encryption Options – Leverage
multiple point of interaction (POI)
devices that can protect both
keyed and swiped data
• Tokenization Options – Support both
single and multi-use tokens
• Freedom to Change - Allow merchants to switch
processors easily, without replacing tokenization
system or encryption devices

3. Encryption-at-Swipe
• OBJECTIVE: Data field encryption should be
implemented at, or as close to card swipe or data
entry as possible – ideally within the device’s read
head or tamper resistant security module (TRSM)
• REQUIREMENT: Merchant is removed from all key
management responsibilities and has no access to
decryption keys or the decryption process

4. Encryption Vendor Selection
• Industry Standard Vendor (no licensing fees)
– DUKPT 3DES encryption (AES forthcoming)
– Every transaction receives a new key
– Encryption occurs within read head
• Proprietary Technology Vendor
– Identity-based encryption eliminates
need for secure injection room
– Works on leading terminals, PIN pads,
wedge, mobile devices
– Supports browser-based page embedded
encryption for secure eCommerce
Both support EMV devices and encrypt manually entered cards
HSMs located in Merchant Link’s data centers

5. Tokenization for Lodging
• Folio Consolidation
– Merge all guest transactions
(room, dining, spa services,
gift shop purchases, etc.)
to one folio/card number
• Guest Satisfaction
– Preferences associated with
the profile can flow to the • Operations
reservation and tie to the – Requires less
same token database storage
• Loyalty / Marketing – Streamlines
– Even if the guest has multiple accounting and
stays (at multiple hotel audit functions
locations with a chain)
the token remains the same

6. Multi-Use Token Design
• Length: 16 digits to easily replace card
numbers in existing systems
• Format: Last 4 digits of the token
are the last 4 digits of the card
number to work seamlessly
with most PMS applications
• Mod-10: Customizable - can be set
to pass or not pass mod-10 validation
• Expiration: Tokens will not expire – the token remains the
same for a card that has been reissued with a new expiration
date (within a particular chain/organization)
• Token ≠ Valid Card #: Tokens should not be mistaken for
legitimate payment card numbers
• Token Boundaries: Only work within specific property/chain

7. Design Considerations
• Bulk Tokenization/Conversion at Implementation
– Automated utility converts all credit card numbers
(historic, current and future)
• Added Security w/Client Certificates
– Helps interrogate which terminals are allowed to
communicate with the vault
• Tokens Used For...
– Incremental and reversal
authorizations
– No show transactions
– Refunds

8. Securing Payments in Lodging

9. Before You Buy, Consider …
Scope – What Impact will my
decision have on PCI Scope?
Form – Single or Multi-Use
Tokens? Format Preserving?
What are my use cases?
Function – Follow-on
Transactions? Manual Entry?
Offline?
Logistics – Deployment and
Replacement Considerations?
Flexibility – Future Options?
Hardware Provider? Processor?

10. Other Considerations
Service / Support
• Fast access to data and ability to troubleshoot
• Responsive, redundant support centers available 24x7x365
Network Reliability / Financial Strength
• Examine network uptime and throughput
– Redundant data centers?
– Transactions per second?
• Examine stability and strength
of company
Flexibility
• Encryption via various POI devices
• Single vs. multi-use tokens
• Processor choice
• POS vendor/device choice