From nobody Mon Nov 28 08:51:25 2016 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFAD129E5B for ; Mon, 28 Nov 2016 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utHiakwAQTqi for ; Mon, 28 Nov 2016 08:51:20 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235F8129D81 for ; Mon, 28 Nov 2016 08:51:19 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Nov 2016 11:51:17 -0500 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Nov 2016 11:51:17 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 11:51:16 -0500 From: Dan Brown To: "dsfjdssdfsd@ietf.org" Thread-Topic: Risks of entropy available Thread-Index: AdJJlYI5iB70z0jIQMOX0DbzkV0LDA== Date: Mon, 28 Nov 2016 16:51:16 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501083C12@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [dsfjdssdfsd] Risks of entropy available X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 16:51:24 -0000 --_004_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Some RNGs (including some versions of Linux /dev/random) have an interface = that exposes the estimated amount of entropy in the secret state of the RNG. If an adversary gains access to this interface, then there is a small risk = that sensitive information leaks to the adversary, because the entropy esti= mate may be derived from and correlated to sensitive information. Just to be clear, I do not see this to be a serious risk. It would be diff= icult to exploit. Yet I do not see enough benefit in this interface to sup= port taking this risk. This issue has probably been discussed elsewhere, maybe with different conc= lusions from, and better reasoning than, mine. If so, then a reply could j= ust point to those discussions. --- More detail sketched out below: The entropy in the RNG must necessarily be derived from secret sources. In= many systems, the secret sources include things like keyboard input timing= s, which can be further classified as sensitive sources. The estimated ent= ropy is also derived in some way from these secret sensitive sources. This= derivation of the estimated entropy is not generally a cryptographically s= trong one-way function. Furthermore, the timing information might be leake= d even if estimation is somehow one-way. Therefore, the interfaces leaks i= nformation about the sensitive sources. For a concrete example, the interface might leak information about the keyb= oard timings, which might in turn leak information about the values of the = key inputs (if, say, there is a correlation between the values and timings,= which might be the case, if say the difference key-down and key-up times v= ary significantly between different keyboard inputs). I don't see much value of providing this estimated-entropy interface at all= . Arguably, system administrators might find it useful to know whether the= system is in a secure state (perhaps to diagnose some kind of problem). Ob= viously, this interface does not escalate a system administrator's already = high privileges. But providing this interface to non-privileged processes = risks exposure of sensitive information to unauthorized processes. A simple way to reduce this risk would be to deny access to non-privileged = users, disallowing them to see the run-time entropy estimate. A more severe recommendation (Barak and Halevi, http://ia.cr/2005/029) is t= o not keep a run-time estimate of entropy. But some security goals do need live entropy, which might suggest using som= e limited run-time entropy estimation. For example, NIST SP 800-90* standa= rds have a notion of prediction resistance (which is similar of Linux /dev/= random's blocking interface). In this mode, the RNG waits until it deems = it has enough, presumably fresh entropy. The ostensible purpose is to reco= ver from past temporary state-exposures. The NIST approach is gather to fr= esh entropy from a live noise source. If this noise source has its entropy= assessed only at design time, not at run-time, then Barak and Halevi's rec= ommendation (of no run-time entropy estimation), can be followed. The NIST = standards might, however, have some mild health test checks of entropy sour= ce, which only aim to detect severe failure, making them only mildly incomp= atible with the Barak-Halevi approach. If I understand correctly, the recent /dev/random approaches are to decreas= e the estimate entropy on an ongoing basis (such as during calls /dev/rando= m), to ensure the current pool is deemed to be fresh entropy. The freshne= ss so obtained might have a purpose similar to NIST's security goal of pred= iction resistance (recovery from temporary state-compromise). Unfortunatel= y, this step of decreasing the entropy estimate increases the risk of the i= nterface. For example, if the entropy is in a near full state, then /dev/= random might cease to increase its entropy estimate. In this full state, t= he leak is reduced or stopped, because the entropy estimate does not change= as often. To circumvent this obstacle, the adversary can draw down the en= tropy estimate by calling /dev/random, thereby cause the RNG to decrease it= s entropy estimate. In so doing, the adversary can change the RNG state fr= om non-leaky back to leaky. (The issue of calls to /dev/random being abuse= d for another purpose to cause a denial of service has already been largely= mitigated by changes in the /dev/random system.) The entropy estimate interface exposes more information than the blocking b= ehavior of something like /dev/random, in that the entropy estimate numbers= contain more information than the single bit of blocked/non-blocked state,= and further the entropy estimate changes more frequently than the blocking= state. But even the blocking behavior of /dev/random has the potential to= leak a miniscule information, such as the timing information. For example= , a malicious non-privileged process might call /dev/random very frequently= until it blocks. Whether another user, say the system administrator, on t= he system types sensitive keyboard input into another process, /dev/random = may unblock. The malicious process can then gather some timing information= about the keyboard inputs. I see this as a much smaller risk, which is ar= guably worth the benefit of the prediction resistance properties of /dev/ra= ndom. Again, the reason it is smaller risk is that blocking state changes = much less frequently than the entropy estimate. Monitoring changes in the = entropy estimate can therefore much more precise timing information. Best regards, Dan Brown [BlackBerry] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Some RNGs (including some versions of Linux /dev/ran= dom) have an interface that exposes the estimated amount of entropy in the = secret state of the RNG.

 

If an adversary gains access to this interface, then= there is a small risk that sensitive information leaks to the adversary, b= ecause the entropy estimate may be derived from and correlated to sensitive= information. 

 

Just to be clear, I do not see this to be a serious = risk.  It would be difficult to exploit.  Yet I do not see enough= benefit in this interface to support taking this risk. 

 

This issue has probably been discussed elsewhere, ma= ybe with different conclusions from, and better reasoning than, mine. = If so, then a reply could just point to those discussions.

 

---

 

More detail sketched out below:

 

The entropy in the RNG must necessarily be derived f= rom secret sources.  In many systems, the secret sources include thing= s like keyboard input timings, which can be further classified as sensitive= sources.  The estimated entropy is also derived in some way from these secret sensitive sources.  This deriva= tion of the estimated entropy is not generally a cryptographically strong o= ne-way function.  Furthermore, the timing information might be leaked = even if estimation is somehow one-way.  Therefore, the interfaces leaks information about the sensitive sources.  <= /o:p>

 

For a concrete example, the interface might leak inf= ormation about the keyboard timings, which might in turn leak information a= bout the values of the key inputs (if, say, there is a correlation between = the values and timings, which might be the case, if say the difference key-down and key-up times vary signific= antly between different keyboard inputs).

 

I don’t see much value of providing this estim= ated-entropy interface at all.  Arguably, system administrators might = find it useful to know whether the system is in a secure state (perhaps to = diagnose some kind of problem). Obviously, this interface does not escalate a system administrator’s already high pr= ivileges.  But providing this interface to non-privileged processes ri= sks exposure of sensitive information to unauthorized processes.=

 

A simple way to reduce this risk would be to deny ac= cess to non-privileged users, disallowing them to see the run-time entropy = estimate.

 

A more severe recommendation (Barak and Halevi, http://ia.cr/2005/029) is to not keep a run-time estimate of entropy.&n= bsp;

 

But some security goals do need live entropy, which = might suggest using some limited run-time entropy estimation.  For exa= mple, NIST SP 800-90* standards have a notion of prediction resistance (whi= ch is similar of Linux /dev/random’s blocking interface).   In this mode, the RNG waits until it deems it has = enough, presumably fresh entropy.  The ostensible purpose is to recove= r from past temporary state-exposures.  The NIST approach is gather to= fresh entropy from a live noise source.  If this noise source has its entropy assessed only at design time, not at run-time, then= Barak and Halevi’s recommendation (of no run-time entropy estimation= ), can be followed. The NIST standards might, however, have some mild healt= h test checks of entropy source, which only aim to detect severe failure, making them only mildly incompatible wi= th the Barak-Halevi approach. 

 

If I understand correctly, the recent /dev/random ap= proaches are to decrease the estimate entropy on an ongoing basis (such as = during calls /dev/random), to ensure the current pool is deemed to be fresh= entropy.   The freshness so obtained might have a purpose similar to NIST’s security goal of prediction r= esistance (recovery from temporary state-compromise).  Unfortunately, = this step of decreasing the entropy estimate increases the risk of the inte= rface.   For example, if the entropy is in a near full state, then /dev/random might cease to increase its entropy es= timate.  In this full state, the leak is reduced or stopped, because t= he entropy estimate does not change as often.  To circumvent this obst= acle, the adversary can draw down the entropy estimate by calling /dev/random, thereby cause the RNG to decrease its ent= ropy estimate.  In so doing, the adversary can change the RNG state fr= om non-leaky back to leaky.  (The issue of calls to /dev/random being = abused for another purpose to cause a denial of service has already been largely mitigated by changes in the /dev/rando= m system.)

 

The entropy estimate interface exposes more informat= ion than the blocking behavior of something like /dev/random, in that the e= ntropy estimate numbers contain more information than the single bit of blo= cked/non-blocked state, and further the entropy estimate changes more frequently than the blocking state. = ; But even the blocking behavior of /dev/random has the potential to leak a= miniscule information, such as the timing information.  For example, = a malicious non-privileged process might call /dev/random very frequently until it blocks.  Whether another user, s= ay the system administrator, on the system types sensitive keyboard input i= nto another process, /dev/random may unblock.  The malicious process c= an then gather some timing information about the keyboard inputs.  I see this as a much smaller risk, which is arg= uably worth the benefit of the prediction resistance properties of /dev/ran= dom.  Again, the reason it is smaller risk is that blocking state chan= ges much less frequently than the entropy estimate.  Monitoring changes in the entropy estimate can therefore m= uch more precise timing information.

 

Best regards,

 

Dan Brown

3D"BlackBerry"

 

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=174; creation-date="Mon, 28 Nov 2016 16:51:15 GMT"; modification-date="Mon, 28 Nov 2016 16:51:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAEklEQVQ4y2NgGAWjYBSMAuwAAAQgAAFWu83mAAAAAElFTkSu QmCC --_004_810C31990B57ED40B2062BA10D43FBF501083C12XMB116CNCrimnet_--