Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FEDC1C3D42; Tue, 21 May 2024 00:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XrMKZzO8G3D; Tue, 21 May 2024 00:52:09 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A21C137367; Tue, 21 May 2024 00:52:08 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-36ddf683ad7so7635785ab.2; Tue, 21 May 2024 00:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716277928; x=1716882728; darn=ietf.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=7+hI3nATfe6WzkmRfIC+MiYHVt4Sk6qX/ZRyTFsNXDo=; b=OxXGZY3wZP9/XOlIdcHhHP8l6kU5JZP+ENvshRlFO82idPhQPd6+at9Lb+BBC/dh3+ av3yCrrWipH5J+LeV9nyPRvj6SMhG/gOfPGfqVDpPZ8nX5myrhTnydX/jWeGnz24BbqB LUS8IjtHDveca4NDyBTq6BAo6Kgte6jfBupogUAEfRyzrRuW6s3cZcjKFVHpaBEHfYNd 49xSlMAzO1eZyGbL+lHDOjxPqn0lQ25TEOerRXu7ls/RSymIdtIT21H02HqLGscwo9wj Fyyad495Y7MRdKz2UWMTvmts2OtX+tXUs0rR9WM2APne3OGN3tEJIRnzaxMLLmX2kHlj oejg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716277928; x=1716882728; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=7+hI3nATfe6WzkmRfIC+MiYHVt4Sk6qX/ZRyTFsNXDo=; b=Bwvgs7h+mVe61LlG/dnm6fma7hsjDvRmsmc9Rfs8dbsARVlVIAhtrGl9ebMo+k94xA XlyZiiRs6HbGcuHLvHvjok2Tne1LilqCx6Cn0I8ymfSmehQHRYS0oBp5cuuCWGgjHAIO jNaA6MLU0EEsgSoesiUBlysLVB9uINwPmxf2HHaqy/REl+2eWDSQdARxMKy9cQKZ0V9o UEQzKW8rU/yGNniEhu4Ijim17sl7PTLjyRGpshRJu6SAwNQz0QoKtxUg7qdird03wDIn 0WM9lc/sta2KSMSIb2PdD30+ONlEgixzgl9mt3J8pMaHe30UVd0PSrEFV7DmDpR7EY6s /r6g== X-Forwarded-Encrypted: i=1; AJvYcCXDfFEK+zAc6TtmRAa0qBQ6egqN+267Z/rBmzc3y9cetGv7VBxMrsJFgoQeHRu4smUTI2HVqbs+BqhO5zIYsss= X-Gm-Message-State: AOJu0Yyc+A5zMRNKgvAo2Uo+eC72K1BreKSWoWfjHnQAQC3iHIQQ4lGV k0TcnfLrsvPWrDrCSoxQGx9WlZK1gMWpPfiZpX20D9zKeXpl/+e0 X-Google-Smtp-Source: AGHT+IGchVZ4R/EGFA9JMXex5CAGy5fynsp/8FY11aDF1j58JuQKRX/dobnwXF0VZs8Ht5/CCcbaUQ== X-Received: by 2002:a05:6e02:1446:b0:36c:80b6:9a28 with SMTP id e9e14a558f8ab-36cc14ab33dmr377719605ab.18.1716277927962; Tue, 21 May 2024 00:52:07 -0700 (PDT) Received: from [192.168.0.49] (75-166-62-170.hlrn.qwest.net. [75.166.62.170]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-36dced145f5sm19774435ab.80.2024.05.21.00.52.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 May 2024 00:52:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------QvbHgGilm9bZOsEslDg9Jh7R" Message-ID: <4c582fa5-eef2-441c-a1e4-ae47430ac771@gmail.com> Date: Tue, 21 May 2024 01:52:06 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Carlos Pignataro , Michael Welzl References: <9C8679E6-4E52-4A5A-A5B5-B55429A0EF51@ifi.uio.no> <547644D7-8EF7-42CF-93BD-F5E2F207DA5E@gmail.com> Content-Language: en-US From: Shawn M Emery In-Reply-To: <547644D7-8EF7-42CF-93BD-F5E2F207DA5E@gmail.com> Message-ID-Hash: TS7FBWQSKTSTYLJFXJSN542ON7EH3A2V X-Message-ID-Hash: TS7FBWQSKTSTYLJFXJSN542ON7EH3A2V X-MailFrom: shawn.emery@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-pignataro-eimpact-icmp.all@ietf.org, secdir@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bsecdir=5D_Re=3A_Secdir_early_review_of_draft-pignataro-eimpact-?= =?utf-8?q?icmp-02?= List-Id: Security Area Directorate Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------QvbHgGilm9bZOsEslDg9Jh7R Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Carlos, If ICMP has no restrictions on response time in ms granularity then an attacker _could_ gather a sequence of power draws on the sensitive component and, as I mentioned before, a divide-and-conquer technique _could_ still be used in order to collect parts of the secret key at different segments of time. First draft at mitigating SCA, either by excluding sensitive components or providing counter-measures, as follows: High-fidelity reporting of power draw for the targeted node's memory, cache, hardware security module, or other sensitive component could allow an attacker to perform a remote side-channel attack (i.e., using differential power analysis) during cryptographic operations.  This attack would allow the adversary to extract the network node's secret key(s) or other sensitive data.  There are a couple of ways of mitigating this type of attack; exclude power metrics for components that process sensitive data or provide countermeasures that introduce noise in the reported power metrics (e.g., software that demarcates sensitive data which signals the processing hardware to treat this data with algorithmic noise).  The latter technique is an area of ongoing research at the time of this writing. Regards, Shawn. -- On 5/18/24 11:51 AM, Carlos Pignataro wrote: > Thanks Shawn and Michael! > > I’d say, Shawn, "very few to none", and devices would share power (not > voltage). > > Based on this discussion, would it then be fair to acknowledge the > potential, and say that there’s ongoing research without providing any > 2119 guidance? > > Like: > > “High-fidelity reporting of power draw for the targeted node's memory, > cache, or other component could allow an attacker to perform a remote > side-channel attack (i.e., using DPA) during cryptographic operations > in order to extract the associated secret key. This is an area of > ongoing research and as such scope and countermeasures being > researched. That said, this document provides a single power value, > not a time series. Concerned vendors could introduce noise in the > reported measure, concerned operators could have operational policies > matching their requirements. “ > > What do you think? Feel free to edit ✍️ 😊 > > > Thanks! > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > >> On May 17, 2024, at 00:38, Michael Welzl wrote: >> >>  Hi all ! >> >> Just a thought: a router or switch may not itself be much involved in >> crypto operations (in the absence of IPSec, and while no encrypted >> management protocol is in use). In such situations, DPA may be a >> non-problem. >> >> Devices can of course abstain from sharing power information. What if >> the security considerations section said that devices should allow >> their owner to configure if they should share this information while >> cryptographic operations are active? >> ( I say “allow their owner to configure” because there may be more >> concerns about sharing power information widely, so anyway an >> administrator may want to configure the device to share this >> information only within a certain network domain. ) >> >> Cheers, >> Michael >> >> >>> On May 17, 2024, at 7:16 AM, Shawn M Emery >>> wrote: >>> >>> Hi Carlos, >>> >>> Comments begin with SME. >>> >>> On 5/12/24 4:41 PM, Carlos Pignataro wrote: >>>> Hi 👋🏼 Shawn, >>>> >>>> Many thanks for this very useful review!!! Very useful! >>> SME: Of course. >>>> We have been thinking about your review comments, tracked at >>>> https://github.com/cpignata/eimpact-icmp/issues/27 , and have some >>>> follow up questions for you (leaving only the relevant part of the >>>> review) >>>> >>>> 1. For DPA (as in differential power analysis), an attacker would >>>> need a “continuous” Current / Power over time curve while the >>>> crypto algo is executed. Would the fact that this is getting a >>>> single value (not a time series) be a fair high level counter measure? >>> SME: This countermeasure is still susceptible to divide-and-conquer >>> attacks, where different parts of the secret key are learned over time. >>>> 2. Do these elements typically have DPA protection as in injecting >>>> noise? Should we in the results? >>> SME: Ideally yes, but this depends on individual >>> component/system/software design and therefore could not assume one >>> way or the other that this type of mitigation has been employed on >>> any given device. >>>> 3. Could you please share a reference to DPA we could use to add >>>> text? And really welcome textual suggestions!!! 😉 >>> >>> SME: Hmmm, this is an area of ongoing research, where promising >>> countermeasures include a holistic approach, such as software >>> flagging sensitive data for the hardware to treat this data with >>> algorithmic noise, i.e., undifferentiated power consumption based on >>> input.  So if this type of mitigation was a MUST in this draft then >>> how many network nodes could currently meet this requirement?  If >>> that answer is "very few to none" then this draft, IMO, would not be >>> an appropriate source to provide guidance on how to counter remote >>> side-channels attacks.  What is the granularity of voltage that >>> would be meaningful as a sustainability metric? >>> >>>> Thanks again, Shawn! >>> >>> SME: NP >>> >>> Regards, >>> >>> Shawn. >>> >>> -- >>> >>>> On Fri, Apr 26, 2024 at 18:49 Shawn Emery via Datatracker >>>> wrote: >>>> >>>> Reviewer: Shawn Emery >>>> Review result: Has Issues >>>> >>>> […] >>>> >>>> >>>> However, one attack vector that I could >>>> think of is a high-fidelity reporting of power draw for the >>>> targeted node's >>>> memory, cache, or HSM component then an attacker could perform >>>> a remote >>>> side-channel attack (i.e., using DPA) during cryptographic >>>> operations in order >>>> to extract the associated secret key. >>>> >>>> General comments: >>>> >>>> Thank you for the use-case section. >>>> >>>> Editorial comments: >>>> >>>> None. >>>> >>>> >>> >> --------------QvbHgGilm9bZOsEslDg9Jh7R Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Carlos,

If ICMP has no restrictions on response time in ms granularity then an attacker _could_ gather a sequence of power draws on the sensitive component and, as I mentioned before, a divide-and-conquer technique _could_ still be used in order to collect parts of the secret key at different segments of time.

First draft at mitigating SCA, either by excluding sensitive components or providing counter-measures, as follows:

High-fidelity reporting of power draw for the targeted node's memory, cache, hardware security module, or other sensitive component could allow an attacker to perform a remote side-channel attack (i.e., using differential power analysis) during cryptographic operations.  This attack would allow the adversary to extract the network node's secret key(s) or other sensitive data.  There are a couple of ways of mitigating this type of attack; exclude power metrics for components that process sensitive data or provide countermeasures that introduce noise in the reported power metrics (e.g., software that demarcates sensitive data which signals the processing hardware to treat this data with algorithmic noise).  The latter technique is an area of ongoing research at the time of this writing.

Regards,

Shawn.
--
On 5/18/24 11:51 AM, Carlos Pignataro wrote:
Thanks Shawn and Michael!

I’d say, Shawn, "very few to none", and devices would share power (not voltage). 

Based on this discussion, would it then be fair to acknowledge the potential, and say that there’s ongoing research without providing any 2119 guidance?

Like:

“High-fidelity reporting of power draw for the targeted node's memory, cache, or other component could allow an attacker to perform a remote side-channel attack (i.e., using DPA) during cryptographic operations in order to extract the associated secret key. This is an area of ongoing research and as such scope and countermeasures being researched. That said, this document provides a single power value, not a time series. Concerned vendors could introduce noise in the reported measure, concerned operators could have operational policies matching their requirements. “

What do you think? Feel free to edit ✍️ 😊 


Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 17, 2024, at 00:38, Michael Welzl <michawe@ifi.uio.no> wrote:

 Hi all !

Just a thought: a router or switch may not itself be much involved in crypto operations (in the absence of IPSec, and while no encrypted management protocol is in use). In such situations, DPA may be a non-problem.

Devices can of course abstain from sharing power information. What if the security considerations section said that devices should allow their owner to configure if they should share this information while cryptographic operations are active?
( I say “allow their owner to configure” because there may be more concerns about sharing power information widely, so anyway an administrator may want to configure the device to share this information only within a certain network domain. )

Cheers,
Michael


On May 17, 2024, at 7:16 AM, Shawn M Emery <shawn.emery@gmail.com> wrote:

Hi Carlos,

Comments begin with SME.

On 5/12/24 4:41 PM, Carlos Pignataro wrote:
Hi 👋🏼 Shawn,

Many thanks for this very useful review!!! Very useful!
SME: Of course.
We have been thinking about your review comments, tracked at
https://github.com/cpignata/eimpact-icmp/issues/27 , and have some follow up questions for you (leaving only the relevant part of the review)

1. For DPA (as in differential power analysis), an attacker would need a “continuous” Current / Power over time curve while the crypto algo is executed. Would the fact that this is getting a single value (not a time series) be a fair high level counter measure?
SME: This countermeasure is still susceptible to divide-and-conquer attacks, where different parts of the secret key are learned over time.
2. Do these elements typically have DPA protection as in injecting noise? Should we in the results?
SME: Ideally yes, but this depends on individual component/system/software design and therefore could not assume one way or the other that this type of mitigation has been employed on any given device.
3. Could you please share a reference to DPA we could use to add text? And really welcome textual suggestions!!! 😉

SME: Hmmm, this is an area of ongoing research, where promising countermeasures include a holistic approach, such as software flagging sensitive data for the hardware to treat this data with algorithmic noise, i.e., undifferentiated power consumption based on input.  So if this type of mitigation was a MUST in this draft then how many network nodes could currently meet this requirement?  If that answer is "very few to none" then this draft, IMO, would not be an appropriate source to provide guidance on how to counter remote side-channels attacks.  What is the granularity of voltage that would be meaningful as a sustainability metric?

Thanks again, Shawn!

SME: NP

Regards,

Shawn.

--

On Fri, Apr 26, 2024 at 18:49 Shawn Emery via Datatracker <noreply@ietf.org> wrote:
Reviewer: Shawn Emery
Review result: Has Issues
[…]

However, one attack vector that I could
think of is a high-fidelity reporting of power draw for the targeted node's
memory, cache, or HSM component then an attacker could perform a remote
side-channel attack (i.e., using DPA) during cryptographic operations in order
to extract the associated secret key.

General comments:

Thank you for the use-case section.

Editorial comments:

None.





--------------QvbHgGilm9bZOsEslDg9Jh7R--