Abstract
swIDch introduces an entirely new type of user authentication factor with the Tap-OTAC solution. Tap-OTAC serves as an empowering option to satisfy Multi-Factor Authentication (MFA) requirements such as PSD2 Strong Customer Authentication (SCA) from Europe and/or FTC’s Safeguards Rule from the United States. Tap-OTAC lets organisations achieve a higher privacy security level over legacy OTPs including SMS or conventional mobile OTP, and it protects your identification against external threats that such legacy OTPs do not cover. Moreover, the Tap-OTAC solution can be straightforwardly applied to a wide variety of smart cards such as bank debit cards, credit cards or even building access cards. Users benefit from both the enhanced security of hardware OTP (hardware token) and the convenience of mobile OTP (software tokens).
What is Multi-Factor Authentication?
As the name implies, Multi-Factor Authentication (MFA) is authentication through verifications of at least two types of authentication factors, which are:
- Knowledge: Something you know (e.g. a password).
- Possession: Something you have (e.g. a token).
- Inherence: Something you are (e.g. biometric characteristics).
Why is MFA needed?
According to Microsoft, MFA can “prevent 99.9 percent of attacks”. While there are some arguments that this number is not realistic, there is no doubt that MFA is highly effective in mitigating security threats such as identity theft. For this reason, companies should enforce or at least give an option to enable MFA to protect users’ sensitive information.
Moreover, there are specific requirements that mandate the use of MFA, especially in financial institutions. In Europe, there is PSD2 “Strong Customer Authentication,” and in the United States, there is FTC’s “Safeguards Rule.”
Protection from cyber-attacks
MFA adds an extra layer of security, protecting from cyber-attacks like:- Social Engineering: Attackers use psychological means to make users give away their sensitive information, like log-in credentials. For instance, attackers create a fake website that looks exactly like the original website. Hackers take all the user inputs from the fake website and use them to sign into the original website. These inputs include email, password, code sent through SMS, and even OTP.
- Credential Stuffing: Attackers use previously leaked credentials from one site to log in to another. If a user has reused the leaked credentials in other websites, attackers can successfully sign into those websites. Automated bots are frequently used for carrying out credential stuffing attacks.
- Password Spraying: Attackers use a set of commonly known or used passwords. The attack is performed on a large set of accounts, hoping that some of these accounts use these weak passwords.
PSD2 Strong Customer Authentication
PSD2 is the “Second (Revised) Payments Services Directive” implemented in January 2018 in the European Union. Strong Customer Authentication (SCA), which is part of PSD2, is a mandatory requirement across Europe for carrying out financial transactions, such as online transactions and bank transfers. SCA requires that the transactions are verified using MFA, a combination of at least two authentication factors, to prevent fraud and protect customer data from malicious attacks.
Most countries in the EU met the SCA requirements by September 2021, with the United Kingdom extending the deadline to March 2022. As of today, the SCA requirement is enforced in all EU countries.
FTC’s Safeguards Rule
The Federal Trade Commission of the United States amended the Safeguards Rule, which is set to protect consumer information, in December 2021. The Safeguards Rule applies to any business defined as a “financial institution.”
While the rule states many requirements, such as encryption, disposal policies, and logging requirements, one of the most significant requirements is that the institutions must implement MFA. Just like SCA, Safeguards Rule requires verification consisting of at least two authentication factors.
An important point to note here is that FTC has excluded SMS text messages as an acceptable example of a possession factor. While this exclusion does not mean that the use of SMS text is prohibited, it is not recommended as a secure means to protect sensitive consumer information. Note that the security and privacy of SMS texts are not guaranteed by mobile carriers, which means attackers can intercept these messages.
What is OTAC?
Based on the world’s first one-way dynamic authentication technology, one-time authentication code (OTAC) originally invented by swIDch provides more secure authentication by uni-directional dynamic token ONLY to overcome bi-directional limitations including high dependency on the push & pull system of network connectivity between clients and servers. By reinventing authentication, swIDch sets a new standard for authentication in cybersecurity beyond the limitations of existing authentication methods.
OTAC can be applied to various products and services across different sectors. It has various solutions including payment, IoT, and military, just to name a few.
swIDch’s OTAC algorithm was put to the test and fully substantiated in a detailed 42-page technical review by the University of Surrey. View the report on their site or download the full report.
![[JPG] OTAC technology table](https://www.swidch.com/hs-fs/hubfs/%5BJPG%5D%20OTAC%20technology%20table.jpg?width=650&name=%5BJPG%5D%20OTAC%20technology%20table.jpg)
What is Tap-OTAC?
swIDch provides Tap-OTAC to protect against external threats that exploit the security vulnerability of mobile OTP by utilizing medium separation which is free from cyber-attacks. It can be easily applied to payment cards such as a debit card and/or credit card, generating non-duplicate and non-reusable OTPs by simply tapping the card on the user's mobile device. It means that users acquire the advantages of hardware OTP (hardware tokens) and mobile OTP (software tokens) at the same time; robust security and convenient user experience.
The Tap-OTAC is embedded in the form of an applet on the IC chip. A card with OTAC applet embedded generates the first OTAC through communication with the smartphone NFC. Since the first code generated from the card is changed into a second ‘OTAC’ via the application, there is no risk of sniffing, something that can occur during standard NFC transactions.
It is available on both iOS and Android platforms - iOS 13 and above or Android OS 6 and above.
How does Tap-OTAC comply with MFA requirements?
Many applications today perform some degree of user authentication using username and password, PIN, or biometrics. However, a lot of them still do not fully comply with the MFA requirements, especially regarding the possession factor. While there are some applications that do implement OTP solutions to tackle the possession factor, many use a weak form of OTPs, such as SMS OTPs, which are prone to many kinds of attacks. Implementing Tap-OTAC can help business solve these problems.
Knowledge Factor / Inherence Factor
Most modern applications, such as banking applications, satisfy the knowledge or the inherence factor by authenticating users with their account number and password, or even with PIN, pattern or biometrics for simpler authentication.
Performing user authentication with an account number and password or with a PIN or pattern constitutes knowledge factors, as they are what the user knows. While using account numbers and passwords has dominated user authentication, more and more applications support simpler authentication through PINs and patterns to satisfy the knowledge factor. When using PIN or pattern as a knowledge factor, they are stored securely in a safe area of the device, such as a keychain or a secure element. Unlike account numbers and passwords, which are stored in the server, PINs and patterns are stored and compared locally on your device, safe from attacks like verifier compromise. In addition, many applications have a safety mechanism to lock the user out after a preset number of unsuccessful tries.
Biometrics are considered an inherence factor as they are inherent characteristics of the user. Using biometric characteristics such as fingerprint or facial recognition usually depends on the biometric authentication features supported by mobile devices. In order to preserve the integrity of the biometric information obtained during the registration, a hash of a unique string that identifies the biometric information is usually stored in the device’s safe area. When a user performs biometric authentication, the application compares the hash string stored during registration with a new hash obtained during authentication, ensuring that the biometric data on the device has not been altered.
Possession Factor
In addition to providing the knowledge or the inherence factors, it is required for the application to prove possession of a registered device to satisfy the MFA requirements. With traditional OTP devices, however, an OTP generated from a lost or stolen device could be used directly in authenticating as the original user. In severe cases, an attacker could install malware on the user’s device to take complete control over it and use an authentication app installed on that device to authenticate successfully into various apps and websites.
The Tap-OTAC is designed in a way that the two devices, the card and the mobile device, are dependent on each other. In other words, the user’s mobile device is required to generate the first OTAC from the card, and the card is needed to generate the final OTAC from the mobile device successfully.
The card has an OTAC applet that requires a unique PIN to access the applet’s functions. This PIN is called an applet PIN and is randomly assigned upon issuing the card. The applet PIN is also stored safely on the server and passed on to the user’s mobile device during the registration process. Note that this applet PIN is not known to the user and is available only to the user’s mobile device. This makes it impossible for the card to independently generate a code without having the user’s mobile device.
After the first OTAC is generated from the card by receiving an application protocol data unit (APDU) command with the applet PIN from the user’s mobile device, the mobile device receives and uses that first OTAC to generate the second or the final OTAC. This “chaining” of the two codes makes the second code dependent on the first, meaning that one must possess the card to generate the final code from the mobile device successfully. Also, the data that is sent through NFC is encrypted, further securing the messages from eavesdropping.
This characteristic of the Tap-OTAC, which explicitly requires the possession and simultaneous interaction between the two devices, adds an additional barrier and makes it extremely challenging to perform attacks through device compromise.
How secure is Tap-OTAC compared to legacy OTPs?
Based on OTAC technology, Tap-OTAC eliminates various weaknesses of other OTPs such as SMS OTP, mobile OTP, and token OTP, thus providing numerous benefits.
- Separates devices physically. Regarding the initial types of OTPs, OTP is obtained solely from a device, whether received by a third party or generated from within the device. This means an attacker could use the OTP to authenticate as the original user if the device gets stolen or captured by malware. However, the Tap-OTAC requires two physically separated devices, the card and the mobile phone, to successfully generate the final OTAC. The first OTAC is generated from the card with a command sent from the user’s device. This command includes an applet PIN, which the application obtains from the server and stores securely during registration. Hence only the registered application on the registered device can send a command to generate the first OTAC successfully. The second or the final OTAC is then generated from the user’s mobile device using the first OTAC received from the card. Without the correct first OTAC generated from the card, the second OTAC output would not match, and the final authentication will fail. As a result, even if the attacker obtains complete control of the victim’s mobile through malware or generates an OTAC from a lost card, the attacker will not be able to authenticate successfully as the original user in either case.
- Prevents malicious attacks. SMS OTP is not considered a safe way to authenticate a user. If the device is stolen, an attacker could easily obtain an OTP sent to the device. Furthermore, the security and privacy of SMS texts are not assured by mobile carriers. Hence SMS messages can be intercepted through methods like SIM swap, number-porting attacks, fake caller IDs, or call forwarding scams operated by dishonest customer service representatives at mobile carriers. Tap-OTAC, on the other hand, is completely secure from such kinds of attacks. The first OTAC is generated from the card and transmitted safely using NFC technology, ensuring proximity between the card and the mobile device. The second or final OTAC generated from the user’s mobile device is sent directly to the server by creating a secure channel.
- Prevents duplicate codes. Unlike other forms of OTPs, OTAC technology is carefully designed in a way that eliminates code duplication with anyone at any given moment. It combines user identification and authentication steps without the possibility of code duplication with other users.
- Identifies user with OTAC. The initial types of OTPs are only effective as a second-factor authentication, meaning that OTPs can only be used with other primary types of authentications like IDs and passwords. When using OTAC, the users or their devices can be identified with the code alone. Once OTAC has been generated, providing the code alone is already fully sufficient to identify the user as the code is unique. This means that you can forget about all the burdens of remembering static information, including IDs and passwords.
- Eliminates the use of special hardware. Hardware OTPs like token-based OTP or OTP cards require special hardware devices designed specifically for generating OTPs. Tap-OTAC, however, comes in the form of an applet, which means it can simply be installed on compatible smart cards. For instance, the OTAC applet can be installed on a standard debit or credit card that we use today, eliminating the need for special hardware that can only generate OTPs. This also benefits the consumers, as they do not have to purchase or carry an additional OTP device to secure their transactions.
- Increases scalability. As mentioned earlier, with Tap-OTAC, the OTAC applet can be installed on compatible smart cards. This means it can be installed not only on debit cards or credit cards but also on access cards or identification cards. OTAC extends the use of such smart cards to provide the ability to authenticate a user during sensitive operations such as bank transfers, access management or KYC.
What is provided with Tap-OTAC?
swIDch provides the necessary parts to implement the Tap-OTAC solution:
- Mobile SDKs to be used in applications. The mobile SDKs should be integrated into the mobile applications for registration, authentication, and deregistration processes. Also, the mobile SDKs require iOS 13 and above or Android OS 6 and above, and the mobile phone has to be NFC compliant.
- An OTAC server module. The OTAC server can be implemented on the client’s backend service. It is responsible for a) creating and storing shared secrets and personalization information to be stored on the card applet and the mobile SDK, b) managing the mapping information between the user account and the user’s card, and c) verifying the card OTAC and the user OTAC.
- An applet to be loaded onto the dual-interface card. The OTAC applet can be mounted on dual-interface cards such as debit or credit cards. During the card issuing process, the bank sends the shared secret and personalization information received from the OTAC server to the card issuer to be stored on the card applet. Note that the dual-interface card should be Java Card 2.2.2+ and have a minimum available storage of 12KB or more for the OTAC applet to be installed.
- Developer guides and implementation sample codes. Lastly, all the necessary documents, guidelines, and sample codes with running sample applications will be provided for easy implementation.
To learn more about Tap-OTAC and many other solutions, please contact us today.
