From day one, Gemini has required 2FA using the Authy service for all accounts. Starting on March 13, 2018 we will be enabling a new Authy feature for added security while performing sensitive transactions: Authy push notifications.

#### Sessions vs transactions

Most consumer-grade authentication systems operate at the level of sessions. Users provide their credentials — which may involve multiple factors such as a password in conjunction with a short-lived, one-time passcode. This initial step creates an authenticated “session” lasting for a fixed duration (e.g., one hour). During this time, users are allowed to browse around the site and use various features. After the clock runs out, the session reverts to an unauthenticated state, requiring users to prove their identity once again.

One shortcoming of this model is that after initial authentication, any number of actions are allowed within the authenticated session. Transactional authentication improves on that model by tying the authentication to a unique action. “Unique” being the operative keyword here: asking users to type their password one more time or even enter another 2FA code is not sufficient. Without knowing what will happen after completing those steps, users are effectively approving _some_ action which may not be what they had in mind.

Phishing attacks and malware can exploit that disconnect. For example, in a phishing attack a user will be mistakenly interacting with a fraudulent copy of the service operated by an attacker. This fake website can:

*   Collect the password
*   Collect a 2FA code

At this point, the attacker can turn around and use those credentials (quickly, before the 2FA code expires) to login to the legitimate website to impersonate the legitimate customer.

Requiring additional 2FA codes to perform sensitive actions such as authorizing a payment is not sufficient to mitigate this. The phishing site can adjust its tactics, feigning an error after collecting the initial 2FA — even though it is valid and used by attacker to login — and trick the user into giving away a _second_ 2FA code to use for authorizing the subsequent action.

While other authentication systems such as U2F are not susceptible to phishing, they have similar limitations against malware. If the device a customer is using to access their favorite website has been compromised by malware, that malicious software can silently alter user actions. For example, it can change the Bitcoin address submitted to a web page in order to funnel payments to a different destination. Not even the proof-of-presence required in U2F by pressing a button helps. While that event cannot be fabricated by malware running on the device — the token itself registers the contact — the user is more than willing to press the button in service of the attacker. After all, they are under the impression that this action will result in some intended, legitimate behavior. In reality it is authorizing _some_ action that can be manipulated under the covers by malware. (Not to mention, malware can wait until authentication is complete to take advantage of the resulting session, complete with all required cookies and even TLS channel binding.)

#### Adding context

The root cause of these problems is lack of context about the action being approved: the user believes that providing a 2FA code or pressing a button will lead to one outcome while the adversary has carefully altered the setup to trigger something else entirely. What is required is an _out-of-band channel_to verify the intended transaction, independent of the original device where it is initiated.

This is far from a new idea; there are many precedents for such verification in high-value scenarios, typically involving special purpose hardware:

*   Some [cryptographic hardware tokens](https://www.ftsafe.com/products/PKI/LCD) feature a trusted display and user-interface with physical buttons to confirm transactions. That display is driven by the token and cannot be manipulated by the machine the token is attached to.
*   Several Bitcoin hardware wallets have a display for confirming the destination addresses on transactions. Even if local malware running on the PC sends a different Bitcoin transaction for signing — as [malware in the wild](https://www.kaspersky.com/blog/cryptoshuffler-bitcoin-stealer/19976/) was discovered to be doing by manipulating the clipboard — the user has an opportunity to detect this substitution because the display cannot be manipulated.
*   A more mainstream example can be found in NFC payments using a smart-phone. While standard credit card payments (even with chip cards) involve blindly trusting the point-of-sale terminal to charge the expected amount, mobile wallets can first [display the amount requested and obtain confirmation](https://www.youtube.com/watch?time_continue=136&v=S5e2EoP_irg&t=1m40s) from the consumer before proceeding with the payment.

#### Introducing Authy Push Notifications

Luckily esoteric hardware is not required to get the benefits of out-of-band authentication. With the right application installed, the ubiquitous smart-phone can function as the independent verification channel. Authy, used by Gemini, is an example of such an app. When customers attempt to withdraw cryptocurrency from their Gemini account, they will receive an approval request on their mobile Authy app containing transaction details:

![](https://cdn-images-1.medium.com/max/800/0*hYv_jA7k0Sc3C1Q5.png)

Unless the transaction is confirmed by clicking on the “Approve” button, no funds will be sent. Note this exchange is taking place on a completely different channel (via the Authy mobile app) than the browser session used to access Gemini. In fact, it is typically taking place on a different _device_altogether: a customer may login to the exchange on their laptop while receiving the notification on their phone. This out-of-band channel is protected from risks associated with the primary device. For example, even if a customer accidentally provides their password and 2FA code to a phishing site, that site has no way to compel that person to approve the notification requesting approval for funds transfer. More importantly, there is no way to obscure or misrepresent the intent of the transaction. Crucial details including amount and destination address will be included in the UI, giving the legitimate customer an opportunity to recognize it for what it is: an attempted theft. Similarly even malware running on the primary device can not in general cause the push notification prompt to be approved outside of user consent. (It would _also_ require compromise of the mobile device to forge that approval.)

#### Roll-out plans

At this time, for customers who are already using the Authy mobile app, Gemini will require push notification approval for all crypto-currency withdrawals — no action is required to opt-in to the additional level of security. Gemini [strongly recommends all customers to use the Authy mobile app](https://gemini.com/blog/better-two-factor-authentication/) and cautions against relying on SMS for two-factor authentication.

If you have any questions, please reach out to our support team at [support@gemini.com](mailto:support@gemini.com).

Onward and Upward,

Gemini Security Team

At Gemini, we take security seriously. 2FA is a requirement to ensure our customers are kept safe when performing sensitive transactions.

Authy Push Notifications for all Gemini accounts

Introducing Authy Push

We have required all of our customers to use two-factor authentication (2FA) from day one. In keeping with our security-first philosophy of protecting and educating our customers, we want to provide some background on our 2FA system **_to encourage our customers to use the Authy app for 2FA rather than SMS_**, and to dispel some common misconceptions.

#### About Authy

Gemini uses the [Authy service](https://www.authy.com/product/) for 2FA. Authy is an independent cloud service called on to perform secondary verification once we have checked that a customer has provided correct login credentials (i.e., email and password).

Authy offers multiple options for second-factor verification:

1.  **SMS**: One-time passcodes (OTPs) are delivered via text message.
2.  **Voice**: Similar to SMS, with the codes read aloud by an automated text-to-speech system.
3.  **Mobile application**: Users install an app (or Chrome extension), which generates an OTP based on a secret “seed” and current time according to the TOTP standard. TOTP is an [open standard](https://tools.ietf.org/html/rfc6238) implemented by multiple apps including [Google Authenticator](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en) [and the Authy app](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en).
4.  **OneTouch**: Pioneered by [Duo Push](https://duo.com/product/trusted-users/two-factor-authentication/authentication-methods/duo-push), this model dispenses with codes altogether. Instead users confirm a login by responding to a simple yes/no prompt.

Each of these options comes with different tradeoffs. **SMS** is simple and can work on any mobile phone including legacy flip-phones that are not “smart” and don’t have an application ecosystem. **Voice** codes further improve accessibility by allowing codes to be sent to landlines or heard by users who have difficulty with visual information.

**TOTP** codes generated using an app do not require internet connectivity. TOTP apps can work offline, even if the phone itself has no service (e.g., when a user is outside a service area). **OneTouch** further improves usability by avoiding the need to transcribe digits from one device to another, but (unlike TOTP) it does require a data connection.

#### Encouraging Mobile Apps

Gemini has always supported SMS and mobile app options for 2FA. However, in recent interactions with customers, the Gemini support team reached the conclusion that many customers were either not aware of the Authy mobile app, incorrectly viewed SMS as equivalently secure to the Authy app, or were interested in other alternative TOTP apps. We are now actively encouraging all of our customers to install the Authy app. We believe that **_switching to the Authy app will improve security without any downside to usability_** for nearly all customers, as discussed below.

At the same time, we recognize there is no one-size-fits-all solution. Customers may have unique requirements which rule out the Authy mobile app, so we will continue to support SMS. However, once you have Authy installed, you will no longer be able to request codes via SMS. We’re doing this to prevent would-be attackers from circumventing the security of the Authy app by falling back to SMS.

#### Risks Associated with SMS

A 2003 [ruling](https://www.fcc.gov/general/wireless-local-number-portability-wlnp) by the Federal Trade Commission (FTC) called for number portability between wireless carriers, which allows consumers to keep their existing phone number when they switch from one wireless carrier to another wireless carrier. Number portability increased competition between wireless carriers by removing one of the major obstacles that prevents consumers from switching to a better plan: the hassle of losing their existing phone number. The FTC ruling made it much easier for consumers to keep their number while switching carriers — too easy, perhaps. Call it the law of unintended consequences: the drive to portability also inadvertently opened the door to [number-porting attacks](https://www.ftc.gov/news-events/blogs/techftc/2016/06/your-mobile-phone-account-could-be-hijacked-identity-thief).

Last July, the National Institute of Standards and Technology (NIST) came out with a [recommendation](https://pages.nist.gov/800-63-3/sp800-63b.html) to deprecate the use of SMS for 2FA. Almost on cue, the industry experienced an uptick in the incidence of phone number hijacking events. In this type of fraud, a miscreant impersonates the legitimate customer and ports his or her number to a _different_ carrier, pretending to be that person switching carriers. If the attacker is successful in convincing the other carrier to reassign the number to an attacker-controlled device, all voice calls and SMS messages will be routed to the perpetrator. As a result, _any_ 2FA system relying on SMS or voice for delivering one-time passcodes is susceptible to such attacks.

#### Setting up the Authy Mobile App

Setting up the Authy mobile app eliminates the risks associated with using SMS for 2FA, however, to fully mitigate SMS vulnerabilities **_you need to make sure you_** [**_turn off_**](https://gemini24.zendesk.com/hc/en-us/articles/115000053543-Turning-off-Authy-Multi-Device-Support) **_“multi-device” in the Authy app._** This prevents the same number-porting attack (mentioned above) from being used to obtain access to your SMS messages to perform an unauthorized install of your Authy account. When it is turned off, no additional instances of the Authy app can be provisioned. We recommend all Gemini customers to keep multi-device disabled, only enabling it **_temporarily_** when setting up a new device (for example, when upgrading your phone). If you’re resetting or trading in your phone, we also recommend that you install the [Authy desktop app](https://www.authy.com/app/desktop/) first, so that you can use it to authorize your new phone. We are also working with the Authy team to make the process of switching or upgrading devices easier and more secure for all Gemini customers, regardless of your multi-device settings.

#### Looking Forward

While using a mobile app to generate codes is an improvement, there are other attack vectors that no 2FA solution based on one-time passcodes (OTPs) can solve. For example, sophisticated phishing attacks can ask users to disclose _both_ their password and an OTP code. This type of phishing is more complex because it requires real-time use of compromised credentials. Since OTPs expire after a short time period, it is not possible to stash the stolen credentials for later use. Despite that added complexity, such attacks are not only feasible in principle but they have been [observed in the wild](https://citizenlab.org/2015/08/iran_two_factor_phishing/) against popular 2FA implementations including those used by Google and some large financial services companies.

These risks cannot be addressed by changing how one-time passcodes are generated or delivered. As long as the possibility exists for a user to be tricked into entering codes into the wrong website, phishing remains a viable attack. For these reasons, **_we are continuing to explore alternative 2FA paradigms such as U2F or Authy OneTouch for Gemini_** which are based on fundamentally different models. (Case in point: our _internal_ systems for administering the exchange use public-key authentication with hardware tokens based on the [PIV standard](http://csrc.nist.gov/groups/SNS/piv/standards.html).) Our priority is to find a solution that combines high security and usability, and is available to our customers across a broad range of platforms.

Better Two-Factor Authentication (2FA)

As a next generation Bitcoin exchange, ensuring the security of bitcoin on deposit is Gemini’s top priority. Perhaps more so than credit-cards, ACH or any other payment systems, Bitcoin is the one payment technology where possession of money can be boiled down to pure cryptographic capability: generating a signature with an ECDSA private key _is money_. If you lose control of that private key, you lose the ability to spend your funds, plain and simple.

With adoption of strong cryptography, direct attacks against cryptographic algorithms and protocols have become increasingly rare, although not extinct, as demonstrated by WEP, MD5, GSM encryption and the never-ending saga of TLS vulnerabilities. Far more common, however, are system failures caused by inadequate key management (i.e. when secrets are mishandled) that allow attackers to bypass the cryptography altogether. To that end, Hardware Security Modules (HSMs) have been promoted as best practice for implementing strict control over private keys. An HSM is a special-purpose, tamper-resistant device for managing cryptographic keys. They are not general-purpose computers meant for everyday use or extensibility; there is no Angry Birds app. In fact, there is no keyboard/mouse or an elaborate LCD display for interacting with the device. Instead they must be connected to a trusted client — an ordinary computer that instructs the HSM over a minimalist interface tailored for cryptography — in order to generate new keys, perform specific operations using those keys and destroy said keys when they are no longer needed or desired.

With respect to Bitcoin companies, many offline “cold” vaulting systems (including Gemini’s) utilize HSMs in an “M-of-N” multi-signature security design whereby HSM transaction signers are held in separate, air-gapped, secure physical storage locations. No one particular HSM can spend funds on its own. Instead, a quorum of several HSMs are required to sign and thereby validate a given transaction with their private keys, effectively making the quorum of HSMs the manifestation of funds on deposit (i.e., money held in custody).

Critical to this security design is that secret keys _never leave the HSM itself_; all operations take place within the secure execution environment of the HSM. For example, when decrypting a message, the ciphertext itself is sent to the device, where it is decrypted using the private keys held by (and inside of) the HSM and the decrypted message is returned back. This is distinct from a non-HSM device that actually reveals the private key to the attached trusted client to “borrow” for performing some operation. It is a fundamental design objective of HSMs to never reveal keys, not even to trusted clients when connected.

At Gemini, we have evaluated several different HSM models. One of the first vendors we reached out to was [Safenet](http://www.safenet-inc.com/ "Safenet"), recently acquired by the French conglomerate Gemalto. Safenet produces a [family of HSMs](http://www.safenet-inc.com/data-encryption/hardware-security-modules-hsms/), ranging from USB-attached compact Luna G5 to the network-connected SA7000, which is used by Amazon in its [CloudHSM](http://aws.amazon.com/cloudhsm/ "CloudHSM") offering where AWS customers can lease access to a device. While evaluating the Luna G5, **_we discovered a vulnerability that allows the extraction of secret keys_**_._ As it turns out, the problem is not unique to the G5; it applies to the entire family, including the PCIe version, as well as the networked appliance featured in CloudHSM.

What makes this vulnerability somewhat unusual is that it is a consequence of _following a standard too closely_, as opposed to the more common problem of diverging from established practices. Safenet HSMs are closely based on the [PKCS#11 specification](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11). This is a de facto standard designed to promote interoperability between cryptographic hardware by providing a consistent software interface. Imagine how difficult it would be to write a cryptographic application — such as a Bitcoin wallet — to work with external hardware if each device required a different API for signing a Bitcoin transaction. Certainly, the differences between devices are apparent: some connect over USB while others are addressed over TCP/IP. Each device typically requires a different device driver much like different brands of printers do. But once your HSM is connected, PKCS11 seeks to provide a higher-level point where these differences can be abstracted behind a unified API, with a vendor-provided PKCS#11 module translating the software concepts into the appropriate commands for that brand of hardware.

PKCS #11 defines a series of “mechanisms” that a particular model of hardware can support. These include the usual suspects such as block ciphers (AES, 3DES, etc.) stream ciphers (RC4) keyed-MACs (HMAC, CBC-MAC), asymmetric encryption (RSA), key-agreement (Diffie-Hellman) and digital signatures (RSA again, ECDSA, etc.). PKCS #11, however, does not mandate that a particular mechanism be implemented by a given device, only a way to interrogate the device hardware to determine what is supported. Vendors can also define additional proprietary mechanisms as long as their identifiers do not conflict with the standard. It turns out that Safenet products implement a substantial amount of PKCS #11-defined mechanisms, and that is the problem. Not all of the ideas in PKCS #11 mechanisms are good. In particular, we found that several key derivation mechanisms create weak keys that can be brute-forced easily to recover the original key in a matter of seconds.

Successful exploit requires authenticated access to the HSM, which can be done by subverting the legitimate trusted client that was using the HSM. That may sound like a prohibitive requirement or even tautological — “if your trusted client is compromised, then your cryptographic keys are also compromised.” But HSMs are specifically designed to _survive_ that threat model — the assumption goes that even if an adversary obtains temporary access to the secure physical storage location of the HSM, they can only perform limited operations with the stored key. They can not just ask the HSM to cough up a copy of its stored secrets. This type of vulnerability breaks that model: temporary access can be leveraged to fully exfiltrate both public and private keys and use them in the future, independent of the device.

As a matter of principle, we do not release weaponized exploits or proof-of-concept code that shows how to utilize a given bug. Instead we practice _responsible disclosure_ by working closely with vendors to help them find a solution to fix vulnerabilities, and then publish our findings after a patch is available to the public. We reported the vulnerability to Safenet on **January 30th, 2015**. It was confirmed by the vendor on **February 11th, 2015** and a security update for affected products has been released on **July 9th, 2015**. We plan to publish a follow-up post with additional technical details. For now it’s worth pointing out that the vulnerability affects all symmetric keys and some private-key types, including ECDSA keys used in Bitcoin. **_If you have been using Safenet HSMs for managing Bitcoin keys, your wallet may be at risk._**  Due to the nature of the vulnerability, it is not possible in all cases for customers to work-around the problem without applying the firmware update. In particular, having the HSM set to strict FIPS mode does not mitigate the risk. We encourage customers to upgrade to the latest version released by Safenet \[[Bulletin](http://www.safenet-inc.com/technical-support/security-updates/)\]. Users leasing an HSM via Amazon CloudHSM service should consult specific instructions provided by AWS.

You can find a more detailed description of this vulnerability [here](https://randomoracle.wordpress.com/2015/08/13/safenet-hsm-key-extraction-vulnerability-part-i/).

CVD ID: [2015–5464](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5464)

Cem Paya

ARTICLES BY Cem Paya

Introducing Authy Push

Better Two-Factor Authentication (2FA)

Your Bitcoin Wallet May Be At Risk: Safenet HSM Key-Extraction Vulnerability

A simple, secure way to buy and sell cryptocurrency