Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CF15DA7 for ; Mon, 9 Apr 2018 23:39:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from algebra.musalbas.com (algebra.musalbas.com [163.172.28.238]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55DDE671 for ; Mon, 9 Apr 2018 23:39:19 +0000 (UTC) Received: from [10.15.0.6] (unknown [10.15.0.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by algebra.musalbas.com (Postfix) with ESMTPSA id 3093512C01AF; Tue, 10 Apr 2018 01:39:17 +0200 (CEST) To: Bitcoin Protocol Discussion , Matias Alejo Garcia , ketamine@national.shitposting.agency References: <84976adb75bef1dfdb12b98c19811278@national.shitposting.agency> <921edfdb-e0e5-8ce4-55d8-ba4e84ef633f@musalbas.com> <010e34a3-f9cf-fba1-5482-de06bc350d64@musalbas.com> From: Mustafa Al-Bassam Message-ID: <69fb5cc4-7b3d-e23d-2b7e-cddcd7b2877b@musalbas.com> Date: Tue, 10 Apr 2018 00:39:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <010e34a3-f9cf-fba1-5482-de06bc350d64@musalbas.com> Content-Type: multipart/alternative; boundary="------------531ED1744281DB8D4C1A1A08" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=musalbas.com; s=dkim; t=1523317157; bh=vZVGsunnPeZvDx/bghvgC5zBeZIMMeOKQh7nJuWA/48=; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type; b=rfqqua7M8iHaxcJGQSd7sITK6USSiPjW+IDb7UnDC50IkO1sYcCdqQr387fPGhkpq7CqS6gP1aV1WxBqU6AmcKLFYOSyruJ36o1U363oFnrDTHh6lnrPeXF0NKdOlnP6gAKaERtpPN6pIk3JT4d0wf7PVCgu97EtXPhiKn+mxD0= X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 23:39:20 -0000 This is a multi-part message in MIME format. --------------531ED1744281DB8D4C1A1A08 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit The original disclosure didn't contain any information about the library in question, so I did some digging. I think that the vulnerability disclosure is referring to a pre-2013 version of jsbn, a JavaScript crypto library. Before it used the CSRNG in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did a string comparison when checking the browser version. In practice though, this doesn't really matter, because navigator.appVersion < "5" returns true anyway for old browsers. The real issue is that modern browsers don't have window.crypto.random defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be using a CSPRNG, when run on a modern browser. As is noted though, even if a CSPRNG is used, the library passes the output of the CSPRNG through RC4, which generates some biased bits, leading to possible private key recovery. On 09/04/18 22:17, Mustafa Al-Bassam via bitcoin-dev wrote: > > And specifically, here's a version of it that uses Arcfour: > https://gist.github.com/jonls/5230850 > > > On 09/04/18 22:11, Mustafa Al-Bassam wrote: >> >> Here's the code in question: https://github.com/jasondavies/jsbn/pull/7 >> >> Best, >> >> Mustafa >> >> >> On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote: >>> Source? >>> >>> On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev >>> >> > wrote: >>> >>> A significant number of past and current cryptocurrency products >>> contain a JavaScript class named SecureRandom(), containing both >>> entropy collection and a PRNG. The entropy collection and the RNG >>> itself are both deficient to the degree that key material can be >>> recovered by a third party with medium complexity. There are a >>> substantial number of variations of this SecureRandom() class in >>> various pieces of software, some with bugs fixed, some with >>> additional >>> bugs added. Products that aren't today vulnerable due to moving to >>> other libraries may be using old keys that have been previously >>> compromised by usage of SecureRandom(). >>> >>> >>> The most common variations of the library attempts to collect >>> entropy >>> from window.crypto's CSPRNG, but due to a type error in a comparison >>> this function is silently stepped over without failing. Entropy is >>> subsequently gathered from math.Random (a 48bit linear congruential >>> generator, seeded by the time in some browsers), and a single >>> execution of a medium resolution timer. In some known configurations >>> this system has substantially less than 48 bits of entropy. >>> >>> The core of the RNG is an implementation of RC4 ("arcfour random"), >>> and the output is often directly used for the creation of >>> private key >>> material as well as cryptographic nonces for ECDSA signatures. >>> RC4 is >>> publicly known to have biases of several bits, which are likely >>> sufficient for a lattice solver to recover a ECDSA private key >>> given a >>> number of signatures. One popular Bitcoin web wallet re-initialized >>> the RC4 state for every signature which makes the biases >>> bit-aligned, >>> but in other cases the Special K would be manifest itself over >>> multiple transactions. >>> >>> >>> Necessary action: >>> >>> * identify and move all funds stored using SecureRandom() >>> >>> * rotate all key material generated by, or has come into contact >>> with any piece of software using SecureRandom() >>> >>> * do not write cryptographic tools in non-type safe languages >>> >>> * don't take the output of a CSPRNG and pass it through RC4 >>> >>> - >>> 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> >>> >>> -- >>> Matías Alejo Garcia >>> @ematiu >>> Roads? Where we're going, we don't need roads! >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------531ED1744281DB8D4C1A1A08 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The original disclosure didn't contain any information about the library in question, so I did some digging.

I think that the vulnerability disclosure is referring to a pre-2013 version of jsbn, a JavaScript crypto library. Before it used the CSRNG in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did a string comparison when checking the browser version.

In practice though, this doesn't really matter, because navigator.appVersion < "5" returns true anyway for old browsers. The real issue is that modern browsers don't have window.crypto.random defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be using a CSPRNG, when run on a modern browser.

As is noted though, even if a CSPRNG is used, the library passes the output of the CSPRNG through RC4, which generates some biased bits, leading to possible private key recovery.


On 09/04/18 22:17, Mustafa Al-Bassam via bitcoin-dev wrote:

And specifically, here's a version of it that uses Arcfour: https://gist.github.com/jonls/5230850


On 09/04/18 22:11, Mustafa Al-Bassam wrote:

Here's the code in question: https://github.com/jasondavies/jsbn/pull/7

Best,

Mustafa


On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote:
Source? 

On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
A significant number of past and current cryptocurrency products
contain a JavaScript class named SecureRandom(), containing both
entropy collection and a PRNG. The entropy collection and the RNG
itself are both deficient to the degree that key material can be
recovered by a third party with medium complexity. There are a
substantial number of variations of this SecureRandom() class in
various pieces of software, some with bugs fixed, some with additional
bugs added. Products that aren't today vulnerable due to moving to
other libraries may be using old keys that have been previously
compromised by usage of SecureRandom().


The most common variations of the library attempts to collect entropy
from window.crypto's CSPRNG, but due to a type error in a comparison
this function is silently stepped over without failing. Entropy is
subsequently gathered from math.Random (a 48bit linear congruential
generator, seeded by the time in some browsers), and a single
execution of a medium resolution timer. In some known configurations
this system has substantially less than 48 bits of entropy.

The core of the RNG is an implementation of RC4 ("arcfour random"),
and the output is often directly used for the creation of private key
material as well as cryptographic nonces for ECDSA signatures. RC4 is
publicly known to have biases of several bits, which are likely
sufficient for a lattice solver to recover a ECDSA private key given a
number of signatures. One popular Bitcoin web wallet re-initialized
the RC4 state for every signature which makes the biases bit-aligned,
but in other cases the Special K would be manifest itself over
multiple transactions.


Necessary action:

  * identify and move all funds stored using SecureRandom()

  * rotate all key material generated by, or has come into contact
    with any piece of software using SecureRandom()

  * do not write cryptographic tools in non-type safe languages

  * don't take the output of a CSPRNG and pass it through RC4

-
3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------531ED1744281DB8D4C1A1A08--