"One survey indicates 44 percent of businesses are reevaluating their use of security tokens, with another 15 percent speeding up already planned evaluations of alternatives. In banking and financial services specifically, as many as 81 percent of respondents indicated that security concerns surrounding tokens have caused their organization to evaluate the use of out-of-band authentication, with 82% indicating their organization is likely to use phone-based authentication."

extracted from - http://www.banktech.com/risk-management/229402308

RSA Advanced Persistent Threat (APT)

On March 17, 2011, RSA announced ^[1] that a cyberattack on its systems was successful and resulted in the compromise and disclosure of information "specifically related to RSA's SecurID two-factor authentication products". While the full extent of the breach remains publicly undisclosed, RSA states that "this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack."

In a filing with the Securities and Exchange Commission (SEC) ^[2], EMC officially disclosed the breach to investors and regulators. EMC indicated it "does not believe that the matter described in the letter and note will have a material impact on its financial results." The filing was accompanied by a copy of their initial announcement, as well as a SecurCare Online Note ^[3], which was made available to their customers. This SecurCare note provides little additional detail, but advises actions that customers should take to protect their infrastructure. These actions fall into the category of best practices, and do not address new risks to infrastructure supporting a SecurID deployment.

Background on SecurID operation

As shown in Figure 1, the SecurID system can be implemented with either a physical hardware token (typically a key-fob or wallet sized card), or a software based token (with implementations for desktop and mobile devices). In either case, the authentication system relies on these tokens to produce a time-synchronized one-time password (OTP) that is unique to a given token and only valid for a brief time.

This function is performed through the use of a proprietary algorithm that uses the current time and an embedded device-specific 128-bit seed to produce a rotating code known as a 'tokencode'. A user authenticates by combining this tokencode with a PIN (Personal Identification Number) to produce a one-time password that is submitted to the server. PINs are not required in all implementations. PINs are created by the user on the first attempted use of a token after deployment or re-assignment. For this reason, PINs may not always be required.

Figure 2. SecurID authentication process

A back-end server (known as ACE/Server) holds these same seeds and algorithm, and can thus perform the same calculation to verify a password was generated from the current tokencode. This process is intended to verify that the client possesses a token, but more accurately indicates that they have knowledge of the appropriate seed and RSA's algorithm. The huge number of possible seeds and constantly changing nature of the tokencodes effectively thwart password guessing and interception attacks. It's generally accepted in cryptography that "If the cryptographic algorithm must remain secret in order for the system to be secure, then the system is less secure."^[6]This axiom is commonly known as Kerckhoffs's Principle. ^[7] The RSA SecurID algorithm is proprietary, but is known to many RSA partners. Efforts have also been made to reverse engineer the algorithm and perform an analysis of the underlying security. ^{[4] [5]} while not fully public, exposure of the algorithm is unlikely to affect overall system integrity.

However, seed secrecy is critical. An exposure of the seed to a third party may allow duplication of tokencodes, and by extension allow the guessing of PINs and one-time passwords.

Impact of the Breach on RSA customers

Due to RSA's public nondisclosure of specific details regarding the nature of the compromise, the impact of this breach on their customers remains largely unknown. However, based on this information and knowledge of SecurID's operation, it's possible to establish theories as to what information may have been compromised. These theories in turn help to formulate response plans.

The compromised information may have related to one or more of the following factors, each of which would potentially impact the integrity of the SecurID system to varying degrees:

§ Records of seeds used in hardware or software tokens manufactured to date

§ Relationship of those seeds to specific token serial numbers

§ Relationship of seeds or token serial numbers to specific clients

§ Information regarding RSA's SecurID algorithm that could expose mathematical and cryptographic weaknesses

§ Information regarding specific implementations of the algorithm that may reveal implementation weaknesses in specific products

§ Source code or other information regarding ACE server that may reveal vulnerabilities

Until further information is available, the prudent course of action is to assume the worst: that SecurID seeds have been exposed, their assignment to specific RSA customers is known, and the source code of ACE server and other products has been compromised and may reveal weaknesses.

EZMCOM Solution

In light of the RSA breach, EZMCOM’s superior software-based authentication form factors provides a better alternative to SecurID tokens at a reduced cost of ownership and 100% customer coverage with ease of use. We have already begun working with organizations that are looking to quickly move off of the RSA platform due to security concerns resulting from the breach. EZMCOM is uniquely positioned to enable rapid implementation and deployment. For banks, EZMCOM’s EzIdentity™ authentication platform can be used to roll out multi-layer, multi-factor strong authentication in just weeks. For enterprise, healthcare, and government organizations, EZMCOM offers off-the-shelf support for a wide range of applications and automated enrolment tools to expedite deployment to their employees. EZMCOM also offers stronger protection from new attacks such as Man-In-The-Middle (MITM), Man-In-The-Browser (MITB), a better user experience, and a lower TCO.

Security Primer of EZMCOM authentication clients

The fundamental approach of seed generation in EZMCOM’s authentication software form factors is dynamic and run-time based. This implies that the seeds are not pre-programmed and are not available at any point of time with participating administrators of Customer (e.g. Banks, Enterprises) or EZMCOM employees.

During the time of EZMCOM Token activation, its user receives via out-of-band channel a randomness (RND-1) generated by the EZMCOM server system. Another random component (RND-2) is generated on the EZMCOM Token side and along with RND-1 as a function of cryptographically strong PBKDF2 algorithm creates the Token seed in run-time. A registration code generated from EZMCOM Token client is then submitted to the server system. This allows the server system to have the RND-2 component for constructing the Token seed.