Being a responsible corporate citizen and member of the local community is at the core of Control Gap’s daily operations. We believe in making work a rewarding experience by incorporating fun team events within our corporate culture, and supporting cause-related and local organizations.

Blog

WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => 1 [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 0, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1994 [post_author] => 2 [post_date] => 2019-04-09 14:30:00 [post_date_gmt] => 2019-04-09 14:30:00 [post_content] =>

NIST recently published a document "Transitioning the Use of Cryptographic Algorithms and Key Lengths" which formalizes the sunset of Triple DES by the end of 2023. Afterwards it will only be recommended for legacy use which means decryption only.

Triple DES (aka TDEA/TDES) is used to protect Web Sites, Virtual Private Networks, remote sessions, e-commerce transactions, and more. TDES is embedded in the hardware of commercial and consumer products including network gear like routers, firewalls, VPNs, and load balancers; and computers like servers, PCs, and laptops. TDES hardware is also widely deployed in the core infrastructure of the financial industry. It powers Point-of-Sale terminals and PIN pads, ATM/ABMs, gas pumps, kiosks, Host Security Modules (HSMs), and more. TDES is supported in standards including ISO, ANSI, and PCI. And there are also many standard mechanisms built upon TDES. It's safe to say that the investment in TDES can be measured in the billions of dollars.

All of these standards bodies have been working diligently on updating everything built upon TDES. Industry has known for a long time that AES would replace TDES. As a result a lot of commercial information security gear has supported both TDES and AES in parallel. Extensive hardware upgrades should not be required. However, much of the migration costs will be on the so-called "soft" side in activities like management, configuration, and transition. The financial industry has additional challenges as changing financial cryptography requires a far more deliberate and careful approach to ensure they comply with a broad range of regulations and standards.

And while they often follow NIST guidance, it's a fairly safe bet that the financial industry will not want to replace or mitigate all of this kit quickly. So this raises some questions:

  • When (not if) they will follow NIST to deprecate TDES?
  • What will their guidance be?

If the financial industry chooses to deviate from NIST and delay sunset there is justification. We've previously recommended considering the strength of use-cases in transition planning and prioritization [See 2]. It is important to remember that while TDES has been deprecated as a general purpose cipher that some use-cases are inherently safer. We know that some of the financial industry's most widely deployed use-cases are safer. So delaying the sunset of these use-cases is neither unreasonable nor unjustified.

Learn More

  1. NIST published (SP) 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Details: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
  2. Article discussing the implications to TDES and PCI: NIST Moves on Sweet32 – 3DES, Blowfish, and Others – Mostly Unsafe https://controlgap.com/blog/nist-moves-on-sweet32/
  3. AES was developed as a replacement for DES. It was standardized in 2001 and includes both stronger keys and stronger block lengths. See https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
  4. Triple DES (aka TDES, TDEA, and 3DES) was a clever way of strengthening and extending DES by using double and triple length keys to drive three encryption rounds. The design facilitated transition from DES using a single key mode. It was introduced in 1995. See https://en.wikipedia.org/wiki/Triple_DES
  5. Single DES was developed from 1973 and approved as a standard in 1976. An effort by EFF broke DES by brute force attack in 1998. See https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
[post_title] => NIST is Sunsetting Triple DES - so what will the Financial Industry do? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-is-sunsetting-triple-des-so-what-will-the-financial-industry-do [to_ping] => [pinged] => https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2019-04-09 14:56:49 [post_modified_gmt] => 2019-04-09 14:56:49 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1994 [menu_order] => 18 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1985 [post_author] => 2 [post_date] => 2019-03-21 17:04:18 [post_date_gmt] => 2019-03-21 17:04:18 [post_content] => Last month NIST announced they were seeking feedback on a proposed updated guidance for FPE. More formally this is SP 800-38G rev 1 "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption". The draft is open for comment until April 15th 2019. The draft as written may cause problems for organizations using FPE to encrypt payment cards. If you provide or use an FPE solution for protecting payment card data you should review this and provide feedback. I would like to thank researchers Hoang and Vaudenay for providing clarifications and insight into their valuable work. However, the opinions are our own.

FPE's Problem in the Payment Card Space

If you aren't familiar with FPE, please take a moment to read our quick history of FPE below. Researchers have identified vulnerabilities in all NIST approved FPE modes where the domain size is small. In English, this means that you can't use FPE safely to encrypt small data elements. Additionally, other findings have led to changes in the underlying algorithm for FF3 (now called FF3-1) [5]. The domain size for both FF1 and FF3 in SP 800-38G was required to be at least one hundred and recommended to be at least one million" [5]. In this update "the recommendation was strengthened to a requirement: the minimum domain size for FF1 and FF3-1 in Draft SP 800-38G Revision 1 is one million". [5].

FPE/Payment Card Challenges

Use of FPE in the financial industry for protecting payment card data faces a number of challenges:
  • The domain may be too small if PAN is constrained by first 6, last 4, and Luhn. This is because the Luhn check invalidates 90% of middle six digits of a 16 digit number.
  • The new recommendations, mean that if FPE should not be used on smaller values such as payment card security codes (CVN, CAV2, CVC2, CID, or CVV2 ) or PIN.
  • Research suggests that FPE seems weaker than NIST's intended 128 bits of security.
  • Solutions in the field have long life spans.
  • Merchants and solution providers would prefer not to have to replace existing solutions they consider relatively new.
  • The rapid progress of researchers in improving attacks calls into question the robustness of the solution.
  • Organizations may need to start thinking about the risk in specific use-cases.

Questions for NIST and the PCI SSC

We know that some FPE solutions preserve all aspects of payment card formatting and don't meet the minimum domain strength of one million in the drafted update. What we don't know:
  1. Can NIST safely reduce the minimum domain size to accommodate this use case?
  2. Will PCI continue to support solutions that do not align to NIST?
  3. And if so, how and for how long?

Is FPE Broken or Bent?

It's difficult enough for the average person to understand encryption, let alone to understand the implications of any "breaks" cryptographers find. Often research takes years to reach the point where things are unsafe and falling apart. Long before that things become bent and practical fixes, work-arounds, and limited use cases can be used to buy time. A case in point, the serious weaknesses in SSLv3 using Cipher-Block-Chaining modes of encryption took more than a decade to fall apart. Eventually researchers were able to demonstrate practical exploitation with attacks like BEAST and POODLE. Afterward, migration away from SSL was largely accomplished in a few years. A few very limited use-cases are still practically safe [3]. They are being deprecated but get more time to migrate. For some time now, nobody should be doing anything new with SSL/CBC. FPE isn't yet broken in a practical sense but it's definitely bent. The state of the art has advanced very quickly. The research today casts doubt on the long term viability of FPE in general use cases even if some use cases remain safe. NIST isn't going to fix FPE if it's totally broken. However, the fix they choose may err on the side of being safe. As an analogy, when cryptographic breaks happen there usually isn't an imminent fire. Don't panic but don't ignore it either. Take a look around, assess the situation, and start planning for an alternative or possible exit. Make no mistake that a fire still may be coming. Just understand that it may be a decade away. Many of the of the recommendations we made after the 2017 announcement in the weakness of FF3 still apply [2].

The Problem of Distinguishability

FPE and other format preserving technologies like FP-tokens, and FP-random-masking, that preserves the first 6, last 4 and Luhn runs into a slightly messy practical problem that has nothing to do with the strength of the cipher [4]. We believe that solution providers should clearly indicate what FP technologies their solutions use. This is not because we believe FPE is bad. But instead because this will help minimize the chance of their customers being caught scrambling if this FP data is discovered or exposed.

A Quick History of FPE

Format Preserving Encryption (FPE) is an interesting a relatively recent technology with a wide range of applications. FPE has been widely adopted to encrypt payment card numbers. FPE can encrypt a valid payment card number to similar but different number matching attributes like the same first 6 and last 4 digits with a valid check digit (Luhn) and reverse the process. If you're skeptical that it sounds like snake-oil, it isn't [1]. Research backing FPE goes back over 20 years. NIST began to consider FPE around 2010-2011 when private industry began making proposals. NIST approved a standard by 2016. But they hedged their bets throughout the process by considering three similar variations of FPE known as FF1, FF2, and FF3. FF2 did not survive to approval. FPE has been subject to intense scrutiny by researchers. By 2017 FF3 was in trouble and NIST effectively put that mode on hold [7] until it could be fixed [5], [6]. Researchers have made some impressive advances in attacks against NIST's FPE and some alternative FP ciphers [8], [9], [10]. In particular the very recent paper on attacking FF3 on large domains [8] has hopefully been addressed in FF3-1.

Learn More

The following references provide background on FPE and its role in PCI compliance.

Articles

  1. What is Format Preserving Encryption and is it suitable for PCI DSS? https://controlgap.com/blog/format-preserving-encryption/
  2. Seven Things You Can Do To Deal With The Recent Format Preserving Encryption (FPE) Compromise https://controlgap.com/blog/7-things-to-do-with-fpe-break/
  3. The Extension of the Sunset of SSL. Safe and unsafe use cases https://controlgap.com/blog/sunset-ssl-extended/
  4. Must Format Preserving Encryption (FPE) be distinguishable from cardholder data for PCI? https://controlgap.com/blog/format-preserving-encryption-and-cardholder-data/

NIST

  1. Request for comment (2019) https://csrc.nist.gov/news/2019/nist-requests-comments-on-draft-sp-800-38g-rev-1
  2. Revision 1 draft to FPE standard (2019) https://csrc.nist.gov/publications/detail/sp/800-38g/rev-1/draft
  3. Recent Cryptanalysis of (FPE mode) FF3 (April 2017) https://csrc.nist.gov/News/2017/Recent-Cryptanalysis-of-FF3

Research

  1. Attacks Only Get Better:How to Break FF3 on Large Domains. Hoang, Miller, Trieu (2019) https://eprint.iacr.org/2019/244
  2. The Curse of Small Domains: New Attacks on Format-Preserving Encryption. Hoang, Tessaro, Trieu (2018) https://eprint.iacr.org/2018/556
  3. Breaking the FF3 Format-Preserving Encryption Standard Over Small Domains. Durak, Vaudenay (2017) https://eprint.iacr.org/2017/521
[post_title] => NIST Update to Format Preserving Encryption Standard affects PCI Use Cases [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-update-to-format-preserving-encryption-standard-affects-pci-use-cases [to_ping] => [pinged] => https://controlgap.com/blog/format-preserving-encryption/ [post_modified] => 2019-03-21 17:04:21 [post_modified_gmt] => 2019-03-21 17:04:21 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1985 [menu_order] => 22 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 30 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1994 [post_author] => 2 [post_date] => 2019-04-09 14:30:00 [post_date_gmt] => 2019-04-09 14:30:00 [post_content] =>

NIST recently published a document "Transitioning the Use of Cryptographic Algorithms and Key Lengths" which formalizes the sunset of Triple DES by the end of 2023. Afterwards it will only be recommended for legacy use which means decryption only.

Triple DES (aka TDEA/TDES) is used to protect Web Sites, Virtual Private Networks, remote sessions, e-commerce transactions, and more. TDES is embedded in the hardware of commercial and consumer products including network gear like routers, firewalls, VPNs, and load balancers; and computers like servers, PCs, and laptops. TDES hardware is also widely deployed in the core infrastructure of the financial industry. It powers Point-of-Sale terminals and PIN pads, ATM/ABMs, gas pumps, kiosks, Host Security Modules (HSMs), and more. TDES is supported in standards including ISO, ANSI, and PCI. And there are also many standard mechanisms built upon TDES. It's safe to say that the investment in TDES can be measured in the billions of dollars.

All of these standards bodies have been working diligently on updating everything built upon TDES. Industry has known for a long time that AES would replace TDES. As a result a lot of commercial information security gear has supported both TDES and AES in parallel. Extensive hardware upgrades should not be required. However, much of the migration costs will be on the so-called "soft" side in activities like management, configuration, and transition. The financial industry has additional challenges as changing financial cryptography requires a far more deliberate and careful approach to ensure they comply with a broad range of regulations and standards.

And while they often follow NIST guidance, it's a fairly safe bet that the financial industry will not want to replace or mitigate all of this kit quickly. So this raises some questions:

  • When (not if) they will follow NIST to deprecate TDES?
  • What will their guidance be?

If the financial industry chooses to deviate from NIST and delay sunset there is justification. We've previously recommended considering the strength of use-cases in transition planning and prioritization [See 2]. It is important to remember that while TDES has been deprecated as a general purpose cipher that some use-cases are inherently safer. We know that some of the financial industry's most widely deployed use-cases are safer. So delaying the sunset of these use-cases is neither unreasonable nor unjustified.

Learn More

  1. NIST published (SP) 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Details: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
  2. Article discussing the implications to TDES and PCI: NIST Moves on Sweet32 – 3DES, Blowfish, and Others – Mostly Unsafe https://controlgap.com/blog/nist-moves-on-sweet32/
  3. AES was developed as a replacement for DES. It was standardized in 2001 and includes both stronger keys and stronger block lengths. See https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
  4. Triple DES (aka TDES, TDEA, and 3DES) was a clever way of strengthening and extending DES by using double and triple length keys to drive three encryption rounds. The design facilitated transition from DES using a single key mode. It was introduced in 1995. See https://en.wikipedia.org/wiki/Triple_DES
  5. Single DES was developed from 1973 and approved as a standard in 1976. An effort by EFF broke DES by brute force attack in 1998. See https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
[post_title] => NIST is Sunsetting Triple DES - so what will the Financial Industry do? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-is-sunsetting-triple-des-so-what-will-the-financial-industry-do [to_ping] => [pinged] => https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2019-04-09 14:56:49 [post_modified_gmt] => 2019-04-09 14:56:49 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1994 [menu_order] => 18 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 53 [max_num_pages] => 18 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 0573d79d0a353cbc766661db59ba41a2 [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => 1 [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 0, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1994 [post_author] => 2 [post_date] => 2019-04-09 14:30:00 [post_date_gmt] => 2019-04-09 14:30:00 [post_content] =>

NIST recently published a document "Transitioning the Use of Cryptographic Algorithms and Key Lengths" which formalizes the sunset of Triple DES by the end of 2023. Afterwards it will only be recommended for legacy use which means decryption only.

Triple DES (aka TDEA/TDES) is used to protect Web Sites, Virtual Private Networks, remote sessions, e-commerce transactions, and more. TDES is embedded in the hardware of commercial and consumer products including network gear like routers, firewalls, VPNs, and load balancers; and computers like servers, PCs, and laptops. TDES hardware is also widely deployed in the core infrastructure of the financial industry. It powers Point-of-Sale terminals and PIN pads, ATM/ABMs, gas pumps, kiosks, Host Security Modules (HSMs), and more. TDES is supported in standards including ISO, ANSI, and PCI. And there are also many standard mechanisms built upon TDES. It's safe to say that the investment in TDES can be measured in the billions of dollars.

All of these standards bodies have been working diligently on updating everything built upon TDES. Industry has known for a long time that AES would replace TDES. As a result a lot of commercial information security gear has supported both TDES and AES in parallel. Extensive hardware upgrades should not be required. However, much of the migration costs will be on the so-called "soft" side in activities like management, configuration, and transition. The financial industry has additional challenges as changing financial cryptography requires a far more deliberate and careful approach to ensure they comply with a broad range of regulations and standards.

And while they often follow NIST guidance, it's a fairly safe bet that the financial industry will not want to replace or mitigate all of this kit quickly. So this raises some questions:

  • When (not if) they will follow NIST to deprecate TDES?
  • What will their guidance be?

If the financial industry chooses to deviate from NIST and delay sunset there is justification. We've previously recommended considering the strength of use-cases in transition planning and prioritization [See 2]. It is important to remember that while TDES has been deprecated as a general purpose cipher that some use-cases are inherently safer. We know that some of the financial industry's most widely deployed use-cases are safer. So delaying the sunset of these use-cases is neither unreasonable nor unjustified.

Learn More

  1. NIST published (SP) 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Details: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
  2. Article discussing the implications to TDES and PCI: NIST Moves on Sweet32 – 3DES, Blowfish, and Others – Mostly Unsafe https://controlgap.com/blog/nist-moves-on-sweet32/
  3. AES was developed as a replacement for DES. It was standardized in 2001 and includes both stronger keys and stronger block lengths. See https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
  4. Triple DES (aka TDES, TDEA, and 3DES) was a clever way of strengthening and extending DES by using double and triple length keys to drive three encryption rounds. The design facilitated transition from DES using a single key mode. It was introduced in 1995. See https://en.wikipedia.org/wiki/Triple_DES
  5. Single DES was developed from 1973 and approved as a standard in 1976. An effort by EFF broke DES by brute force attack in 1998. See https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
[post_title] => NIST is Sunsetting Triple DES - so what will the Financial Industry do? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-is-sunsetting-triple-des-so-what-will-the-financial-industry-do [to_ping] => [pinged] => https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2019-04-09 14:56:49 [post_modified_gmt] => 2019-04-09 14:56:49 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1994 [menu_order] => 18 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1985 [post_author] => 2 [post_date] => 2019-03-21 17:04:18 [post_date_gmt] => 2019-03-21 17:04:18 [post_content] => Last month NIST announced they were seeking feedback on a proposed updated guidance for FPE. More formally this is SP 800-38G rev 1 "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption". The draft is open for comment until April 15th 2019. The draft as written may cause problems for organizations using FPE to encrypt payment cards. If you provide or use an FPE solution for protecting payment card data you should review this and provide feedback. I would like to thank researchers Hoang and Vaudenay for providing clarifications and insight into their valuable work. However, the opinions are our own.

FPE's Problem in the Payment Card Space

If you aren't familiar with FPE, please take a moment to read our quick history of FPE below. Researchers have identified vulnerabilities in all NIST approved FPE modes where the domain size is small. In English, this means that you can't use FPE safely to encrypt small data elements. Additionally, other findings have led to changes in the underlying algorithm for FF3 (now called FF3-1) [5]. The domain size for both FF1 and FF3 in SP 800-38G was required to be at least one hundred and recommended to be at least one million" [5]. In this update "the recommendation was strengthened to a requirement: the minimum domain size for FF1 and FF3-1 in Draft SP 800-38G Revision 1 is one million". [5].

FPE/Payment Card Challenges

Use of FPE in the financial industry for protecting payment card data faces a number of challenges:
  • The domain may be too small if PAN is constrained by first 6, last 4, and Luhn. This is because the Luhn check invalidates 90% of middle six digits of a 16 digit number.
  • The new recommendations, mean that if FPE should not be used on smaller values such as payment card security codes (CVN, CAV2, CVC2, CID, or CVV2 ) or PIN.
  • Research suggests that FPE seems weaker than NIST's intended 128 bits of security.
  • Solutions in the field have long life spans.
  • Merchants and solution providers would prefer not to have to replace existing solutions they consider relatively new.
  • The rapid progress of researchers in improving attacks calls into question the robustness of the solution.
  • Organizations may need to start thinking about the risk in specific use-cases.

Questions for NIST and the PCI SSC

We know that some FPE solutions preserve all aspects of payment card formatting and don't meet the minimum domain strength of one million in the drafted update. What we don't know:
  1. Can NIST safely reduce the minimum domain size to accommodate this use case?
  2. Will PCI continue to support solutions that do not align to NIST?
  3. And if so, how and for how long?

Is FPE Broken or Bent?

It's difficult enough for the average person to understand encryption, let alone to understand the implications of any "breaks" cryptographers find. Often research takes years to reach the point where things are unsafe and falling apart. Long before that things become bent and practical fixes, work-arounds, and limited use cases can be used to buy time. A case in point, the serious weaknesses in SSLv3 using Cipher-Block-Chaining modes of encryption took more than a decade to fall apart. Eventually researchers were able to demonstrate practical exploitation with attacks like BEAST and POODLE. Afterward, migration away from SSL was largely accomplished in a few years. A few very limited use-cases are still practically safe [3]. They are being deprecated but get more time to migrate. For some time now, nobody should be doing anything new with SSL/CBC. FPE isn't yet broken in a practical sense but it's definitely bent. The state of the art has advanced very quickly. The research today casts doubt on the long term viability of FPE in general use cases even if some use cases remain safe. NIST isn't going to fix FPE if it's totally broken. However, the fix they choose may err on the side of being safe. As an analogy, when cryptographic breaks happen there usually isn't an imminent fire. Don't panic but don't ignore it either. Take a look around, assess the situation, and start planning for an alternative or possible exit. Make no mistake that a fire still may be coming. Just understand that it may be a decade away. Many of the of the recommendations we made after the 2017 announcement in the weakness of FF3 still apply [2].

The Problem of Distinguishability

FPE and other format preserving technologies like FP-tokens, and FP-random-masking, that preserves the first 6, last 4 and Luhn runs into a slightly messy practical problem that has nothing to do with the strength of the cipher [4]. We believe that solution providers should clearly indicate what FP technologies their solutions use. This is not because we believe FPE is bad. But instead because this will help minimize the chance of their customers being caught scrambling if this FP data is discovered or exposed.

A Quick History of FPE

Format Preserving Encryption (FPE) is an interesting a relatively recent technology with a wide range of applications. FPE has been widely adopted to encrypt payment card numbers. FPE can encrypt a valid payment card number to similar but different number matching attributes like the same first 6 and last 4 digits with a valid check digit (Luhn) and reverse the process. If you're skeptical that it sounds like snake-oil, it isn't [1]. Research backing FPE goes back over 20 years. NIST began to consider FPE around 2010-2011 when private industry began making proposals. NIST approved a standard by 2016. But they hedged their bets throughout the process by considering three similar variations of FPE known as FF1, FF2, and FF3. FF2 did not survive to approval. FPE has been subject to intense scrutiny by researchers. By 2017 FF3 was in trouble and NIST effectively put that mode on hold [7] until it could be fixed [5], [6]. Researchers have made some impressive advances in attacks against NIST's FPE and some alternative FP ciphers [8], [9], [10]. In particular the very recent paper on attacking FF3 on large domains [8] has hopefully been addressed in FF3-1.

Learn More

The following references provide background on FPE and its role in PCI compliance.

Articles

  1. What is Format Preserving Encryption and is it suitable for PCI DSS? https://controlgap.com/blog/format-preserving-encryption/
  2. Seven Things You Can Do To Deal With The Recent Format Preserving Encryption (FPE) Compromise https://controlgap.com/blog/7-things-to-do-with-fpe-break/
  3. The Extension of the Sunset of SSL. Safe and unsafe use cases https://controlgap.com/blog/sunset-ssl-extended/
  4. Must Format Preserving Encryption (FPE) be distinguishable from cardholder data for PCI? https://controlgap.com/blog/format-preserving-encryption-and-cardholder-data/

NIST

  1. Request for comment (2019) https://csrc.nist.gov/news/2019/nist-requests-comments-on-draft-sp-800-38g-rev-1
  2. Revision 1 draft to FPE standard (2019) https://csrc.nist.gov/publications/detail/sp/800-38g/rev-1/draft
  3. Recent Cryptanalysis of (FPE mode) FF3 (April 2017) https://csrc.nist.gov/News/2017/Recent-Cryptanalysis-of-FF3

Research

  1. Attacks Only Get Better:How to Break FF3 on Large Domains. Hoang, Miller, Trieu (2019) https://eprint.iacr.org/2019/244
  2. The Curse of Small Domains: New Attacks on Format-Preserving Encryption. Hoang, Tessaro, Trieu (2018) https://eprint.iacr.org/2018/556
  3. Breaking the FF3 Format-Preserving Encryption Standard Over Small Domains. Durak, Vaudenay (2017) https://eprint.iacr.org/2017/521
[post_title] => NIST Update to Format Preserving Encryption Standard affects PCI Use Cases [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-update-to-format-preserving-encryption-standard-affects-pci-use-cases [to_ping] => [pinged] => https://controlgap.com/blog/format-preserving-encryption/ [post_modified] => 2019-03-21 17:04:21 [post_modified_gmt] => 2019-03-21 17:04:21 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1985 [menu_order] => 22 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 30 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1994 [post_author] => 2 [post_date] => 2019-04-09 14:30:00 [post_date_gmt] => 2019-04-09 14:30:00 [post_content] =>

NIST recently published a document "Transitioning the Use of Cryptographic Algorithms and Key Lengths" which formalizes the sunset of Triple DES by the end of 2023. Afterwards it will only be recommended for legacy use which means decryption only.

Triple DES (aka TDEA/TDES) is used to protect Web Sites, Virtual Private Networks, remote sessions, e-commerce transactions, and more. TDES is embedded in the hardware of commercial and consumer products including network gear like routers, firewalls, VPNs, and load balancers; and computers like servers, PCs, and laptops. TDES hardware is also widely deployed in the core infrastructure of the financial industry. It powers Point-of-Sale terminals and PIN pads, ATM/ABMs, gas pumps, kiosks, Host Security Modules (HSMs), and more. TDES is supported in standards including ISO, ANSI, and PCI. And there are also many standard mechanisms built upon TDES. It's safe to say that the investment in TDES can be measured in the billions of dollars.

All of these standards bodies have been working diligently on updating everything built upon TDES. Industry has known for a long time that AES would replace TDES. As a result a lot of commercial information security gear has supported both TDES and AES in parallel. Extensive hardware upgrades should not be required. However, much of the migration costs will be on the so-called "soft" side in activities like management, configuration, and transition. The financial industry has additional challenges as changing financial cryptography requires a far more deliberate and careful approach to ensure they comply with a broad range of regulations and standards.

And while they often follow NIST guidance, it's a fairly safe bet that the financial industry will not want to replace or mitigate all of this kit quickly. So this raises some questions:

  • When (not if) they will follow NIST to deprecate TDES?
  • What will their guidance be?

If the financial industry chooses to deviate from NIST and delay sunset there is justification. We've previously recommended considering the strength of use-cases in transition planning and prioritization [See 2]. It is important to remember that while TDES has been deprecated as a general purpose cipher that some use-cases are inherently safer. We know that some of the financial industry's most widely deployed use-cases are safer. So delaying the sunset of these use-cases is neither unreasonable nor unjustified.

Learn More

  1. NIST published (SP) 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Details: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
  2. Article discussing the implications to TDES and PCI: NIST Moves on Sweet32 – 3DES, Blowfish, and Others – Mostly Unsafe https://controlgap.com/blog/nist-moves-on-sweet32/
  3. AES was developed as a replacement for DES. It was standardized in 2001 and includes both stronger keys and stronger block lengths. See https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
  4. Triple DES (aka TDES, TDEA, and 3DES) was a clever way of strengthening and extending DES by using double and triple length keys to drive three encryption rounds. The design facilitated transition from DES using a single key mode. It was introduced in 1995. See https://en.wikipedia.org/wiki/Triple_DES
  5. Single DES was developed from 1973 and approved as a standard in 1976. An effort by EFF broke DES by brute force attack in 1998. See https://en.wikipedia.org/wiki/Data_Encryption_Standard#Chronology
[post_title] => NIST is Sunsetting Triple DES - so what will the Financial Industry do? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => nist-is-sunsetting-triple-des-so-what-will-the-financial-industry-do [to_ping] => [pinged] => https://controlgap.com/blog/nist-moves-on-sweet32/ [post_modified] => 2019-04-09 14:56:49 [post_modified_gmt] => 2019-04-09 14:56:49 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1994 [menu_order] => 18 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 53 [max_num_pages] => 18 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 0573d79d0a353cbc766661db59ba41a2 [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
NIST is Sunsetting Triple DES – so what will the Financial Industry do?
April 9 2019

NIST recently published a document “Transitioning the Use of Cryptographic Algorithms and Key Lengths” which formalizes the sunset of Triple DES by the end of 2023. Afterwards it will only be recommended for legacy use which means decryption only. Triple DES (aka TDEA/TDES) is used to protect Web Sites, Virtual Private Networks, remote sessions, e-commerce

Read More
NIST Update to Format Preserving Encryption Standard affects PCI Use Cases
March 21 2019

Last month NIST announced they were seeking feedback on a proposed updated guidance for FPE. More formally this is SP 800-38G rev 1 “Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption”. The draft is open for comment until April 15th 2019. The draft as written may cause problems for organizations using FPE

Read More
PCI SPoC (PIN on COTS) – Grand Experiment in Mobile Payments
January 28 2019

Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security – Software PIN on COTS (SPoC) – a subset of “PIN-on-glass”. SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment

Read More

e-newsletter

Want important PCI information delivered to you? Sign-up to our e-newsletter and be the first one to know about industry news and trend, offers and promotions.

×

Contact

×

PCI Pilot™ is coming soon!

Our highly-anticipated online tool will be launching very soon to make your PCI SAQ process quick and seamless.

Sign-up today and be among the first to know when PCI Pilot™ is live!