From nobody Thu Jan 11 12:20:02 2018 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 430A812E034 for ; Thu, 11 Jan 2018 12:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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, T_RP_MATCHES_RCVD=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 ZvdxEhoIGlvU for ; Thu, 11 Jan 2018 12:19:41 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8BF12EC4B for ; Thu, 11 Jan 2018 12:19:32 -0800 (PST) X-Spoof: Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2018 15:19:31 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0319.002; Thu, 11 Jan 2018 15:19:31 -0500 From: Dan Brown To: Dan Brown , "dsfjdssdfsd@ietf.org" Thread-Topic: Risks of entropy available Thread-Index: AdJJlYI5iB70z0jIQMOX0DbzkV0LDFBgHS8A Date: Thu, 11 Jan 2018 20:19:30 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501C15EDD@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501083C12@XMB116CNC.rim.net> In-Reply-To: <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.252] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [dsfjdssdfsd] Risks of entropy available X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 11 Jan 2018 20:19:53 -0000 --_004_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi random readers, The threat model of Spectre https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) is an adversarial process running on a target's machine. In the mail below, I describe a similar threat model (on OSes with a RNG wh= ose entropy estimate is accessible by any user), but I expect of much lower= magnitude (i.e. negligible). I certainly don't understand all the computer security issues, so I am only= hoping for confirmation that the magnitude is negligible. For example, maybe it is already normal practice (via sandboxing, chroot, w= hatever), to deny potentially adversarial processes the entropy estimates o= f OS-provided RNGs (i.e. among many other sensitive resources requiring pri= vilege, e.g. the whole filesystem). I think I outlined in the previous ema= il, various other reasons it is not a real concern. Best regards, Dan PS: To re-iterate, I am NOT saying the risk here is comparable to Spectre. = Spectre sidesteps many normal access control measures, e.g. sandboxing, wh= ereas I think the threat in this email would be thwarted by the same measur= es, making it very routine. From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Dan Br= own Sent: Monday, November 28, 2016 11:51 AM To: dsfjdssdfsd@ietf.org Subject: [dsfjdssdfsd] Risks of entropy available 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. --------------------------------------------------------------------- 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_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi random readers,

 

The threat model of Spectre

https://en.wikipedia.org/wiki/Spectre_(security_vuln= erability)

is an adversarial process running on a target’= s machine.

 

In the mail below, I describe a similar threat model= (on OSes with a RNG whose entropy estimate is accessible by any user), but= I expect of much lower magnitude (i.e. negligible).

 

I certainly don’t understand all the computer = security issues, so I am only hoping for confirmation that the magnitude is= negligible. 

 

For example, maybe it is already normal practice (vi= a sandboxing, chroot, whatever), to deny potentially adversarial processes = the entropy estimates of OS-provided RNGs (i.e. among many other sensitive = resources requiring privilege, e.g. the whole filesystem).  I think I outlined in the previous email, var= ious other reasons it is not a real concern. 

 

Best regards,

 

Dan

 

PS: To re-iterate, I am NOT saying the risk here is = comparable to Spectre.  Spectre sidesteps many normal access control m= easures, e.g. sandboxing, whereas I think the threat in this email would be= thwarted by the same measures, making it very routine.

 

From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces= @ietf.org] On Behalf Of Dan Brown
Sent: Monday, November 28, 2016 11:51 AM
To: dsfjdssdfsd@ietf.org
Subject: [dsfjdssdfsd] Risks of entropy available

 

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

 

----------------------------------------------------= -----------------
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 rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=

---------------------------------------------------------------------
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_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=174; creation-date="Thu, 11 Jan 2018 20:19:30 GMT"; modification-date="Thu, 11 Jan 2018 20:19:30 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAEklEQVQ4y2NgGAWjYBSMAuwAAAQgAAFWu83mAAAAAElFTkSu QmCC --_004_810C31990B57ED40B2062BA10D43FBF501C15EDDXMB116CNCrimnet_-- From nobody Thu Jan 11 14:49:58 2018 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 16CF4127333 for ; Thu, 11 Jan 2018 14:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org 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 Xnjcrs4aSc5T for ; Thu, 11 Jan 2018 14:49:56 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAECB12D848 for ; Thu, 11 Jan 2018 14:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=S6Vs0L9aj1J4E4VEQIFYMpBXd4G/UQztb12wEB5gLg4=; b=Ghx9N/gn6ERbfjEp6kOwx0mIOV LmfgVL6mUGcbmGSAC+FlXLCFub968FlcRjgUiVkIIyWSngtL+VKvEY6xBaMRqpvXgzHG8XrXm2v5v URoBw3QFacJtHHqNvNpYrzAon5ILMPr4TlUCZ5qHh/mxqwp5ROWn+5qyiVDjqOdgzAVo=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1eZlfW-0006i7-V2; Thu, 11 Jan 2018 22:49:55 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id D4DB9C001F1; Thu, 11 Jan 2018 17:49:53 -0500 (EST) Date: Thu, 11 Jan 2018 17:49:53 -0500 From: Theodore Ts'o To: Dan Brown Cc: "dsfjdssdfsd@ietf.org" Message-ID: <20180111224953.GL19241@thunk.org> References: <810C31990B57ED40B2062BA10D43FBF501083C12@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501C15EDD@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501C15EDD@XMB116CNC.rim.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [dsfjdssdfsd] Risks of entropy available X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 11 Jan 2018 22:49:58 -0000 On Thu, Jan 11, 2018 at 08:19:30PM +0000, Dan Brown wrote: > > If an adversary gains access to this interface, then there is a > small risk that sensitive information leaks to the adversary, > because the entropy estimate may be derived from and correlated to > sensitive information. I'll note that most of the entropy is coming from interrupt timing, and we use timing from many interrupts for a single bit. One can get more information about what is going on with the system using /proc/interrupts. You'll get far more detail about keyboard timings from /proc/interrupts. You can also find out what's happening with incoming network packets using ifconfig.... and then there's vmstat, iostat, ps, etc., etc. So there's quite a lot of system interfaces one would have to restrict before I would even *start* worrying about the entropy count. Regards, - Ted