Geoff KriegVP of Product Management, Merchant Link
A Flexible, Layered Approach               to Security• Acquirer Neutral – Enable merchants  and franchisees to process vi...
Encryption-at-Swipe• OBJECTIVE: Data field encryption should be  implemented at, or as close to card swipe or data  entry ...
Encryption Vendor Selection• Industry Standard Vendor (no licensing fees)    – DUKPT 3DES encryption (AES forthcoming)    ...
Tokenization for Lodging• Folio Consolidation   – Merge all guest transactions     (room, dining, spa services,     gift s...
Multi-Use Token Design• Length: 16 digits to easily replace card  numbers in existing systems• Format: Last 4 digits of th...
Design Considerations• Bulk Tokenization/Conversion at Implementation   – Automated utility converts all credit card numbe...
Securing Payments in Lodging
Before You Buy, Consider …Scope – What Impact will my decision have on PCI Scope?Form – Single or Multi-Use Tokens? Format...
Other ConsiderationsService / Support• Fast access to data and ability to troubleshoot• Responsive, redundant support cent...
Upcoming SlideShare
Loading in …5
×

HITEC 2012: Hard Codes to Crack: Tokenization, Encryption-at-Swipe and Friends

504 views

Published on

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.

Published in: Technology, Economy & Finance
  • Be the first to comment

  • Be the first to like this

HITEC 2012: Hard Codes to Crack: Tokenization, Encryption-at-Swipe and Friends

  1. 1. Geoff KriegVP of Product Management, Merchant Link
  2. 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. 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. 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. 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. 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. 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. 8. Securing Payments in Lodging
  9. 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. 10. Other ConsiderationsService / Support• Fast access to data and ability to troubleshoot• Responsive, redundant support centers available 24x7x365Network Reliability / Financial Strength• Examine network uptime and throughput – Redundant data centers? – Transactions per second?• Examine stability and strength of companyFlexibility• Encryption via various POI devices• Single vs. multi-use tokens• Processor choice• POS vendor/device choice

×