Subject: [Cfrg] Encrypt in place guidance

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 14:30:06 -0400

The problem is in the Unmanned Aircraft broadcast messages (see DRIP work).

In the System Message defined in ASTM F3411-19 there are 8 bytes of 
sensitive Operator Information that I want to encrypt.  I can get a 
shared secret via the PK mechanism in ECIES.

The challenge is in encrypting, then decrypting these 8 bytes.

There is no room for expansion in the message.  All we have are these 8 
bytes.

There is nothing unique in each System Message to use an an IV. There 
are 7 bytes of mission information and 1 byte of flags that are constant 
for a given mission (but may be the same in a later mission).

There are 8 reserved bytes, but I feel they left out 4 bytes of 
important Operator Information (thus making 12 bytes to encrypt). So no 
grabbing those reserved bytes.

Since this information is of limited value for some period after the 
completion of the mission, I was considering just using AES-ECB.

Opps.   I need 16 bytes for the output of AES-ECB.  Or at least that is 
my reading of the ECB mode.

So I am seeking guidance here on what cipher to use in this particular 
situation.

Thank you.

---

From: Henry B Hotz <[email-masked]>
Date: Tue, 31 Mar 2020 11:55:37 -0700

What about format preserving encryption?

Personal email. [email-masked]

> On Mar 31, 2020, at 11:30 AM, Robert Moskowitz <[email-masked]> wrote:
> 
> In the System Message defined in ASTM F3411-19 there are 8 bytes of sensitive Operator Information that I want to encrypt.  I can get a shared secret via the PK mechanism in ECIES.
> 
> There is no room for expansion in the message.  All we have are these 8 bytes.
> 
> There is nothing unique in each System Message to use an an IV. There are 7 bytes of mission information and 1 byte of flags that are constant for a given mission (but may be the same in a later mission).
> 
> There are 8 reserved bytes, but I feel they left out 4 bytes of important Operator Information (thus making 12 bytes to encrypt). So no grabbing those reserved bytes.
> 
> Since this information is of limited value for some period after the completion of the mission, I was considering just using AES-ECB.
> 
> Opps.   I need 16 bytes for the output of AES-ECB.  Or at least that is my reading of the ECB mode.
> 
> So I am seeking guidance here on what cipher to use in this particular situation.
> 
> Thank you.
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 15:03:24 -0400

> What about format preserving encryption?

Can you point me to info on this?

I am only marginally familiar with it.  Not something I have had 
occation to study.

Thanks.

---

From: Russ Housley <[email-masked]>
Date: Tue, 31 Mar 2020 15:03:52 -0400

Counter mode can be used to encrypt any number of bits without expansion as long as you have a convention for the place to start using the key stream,  In your case, you will not need more than one block, so the convention is which counter value to encrypt to produce the key stream.

Russ

> On Mar 31, 2020, at 2:30 PM, Robert Moskowitz <[email-masked]> wrote:
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 15:08:15 -0400

> Counter mode can be used to encrypt any number of bits without expansion as long as you have a convention for the place to start using the key stream,  In your case, you will not need more than one…

In a private thread, this was pointed out to me.  The operator does 
register the mission and this is how the ECIES keys are exchanged. Not 
much to add an operator timestamp and thus the counter start value.

Actually such a timestamp should already be in the USS 'state' for the 
mission.

This leaves:  CTR or CFB.

---

From: Dan Brown <[email-masked]>
Date: Tue, 31 Mar 2020 20:09:20 +0000

> -----Original Message-----
> From: Cfrg <[email-masked]> On Behalf Of Robert Moskowitz

> ... there are 8 bytes of
> sensitive ... Information that I want to encrypt.  I can get a shared
> secret via the PK mechanism in ECIES.

It sounds like "PK mechanism in ECIES" refers to basic ECDH and you want to know about symmetric-key encryption modes.

I will first talk about ECIES as a whole, then I will try to talk about modes, even though I know very little.

***

ECIES = Elliptic Curve Integrated Encryption Scheme, a public-key encryption scheme, i.e. with a functionality similar to RSA-OAEP, and various other PKEs.

Again, it is not clear to me that you are wholly using ECIES. Indeed, it is not exactly what your problem is.

Do both sides have static public keys?  Yes, I should read the DRIP documents ...

Anyway, ECIES is for when the recipient has a static PK, but the sender does not.

I think there are CFRG proposals or work items that extend ECIES to "Hybrid ..." and that add features like mutual authentication, etc. 

> There is no room for expansion in the message.  All we have are these 8 bytes.

Well, ECIES has built-in message expansion, not only from the ECDH part (which you mentioned) but also because it provides integrity, internally via a MAC tag.

To review, most versions of ECIES are hybrid, combining ECDH with a symmetric key stuff, but they generally drop the IV from the symmetric key mode, informally because ECDH (1) already serves the randomization role of IV, and (2) the symmetric key shared secret is only used once.  In other words, the usual IV (randomization) does not contribute to the message expansion of ECIES.

To avoid message expansion from the MAC, you could truncate the part of the ECIES ciphertext that corresponds to the MAC, but doing so would *modifies* the design of ECIES and thereby introduces potentially serious attack such as chosen ciphertext attacks.  

If you are not worried about these attacks, for some reason, such as have an alternative authentication mechanism, then you might consider with the truncation.

In ECIES as specified in SEC1, v.2.0, there are several choices of symmetric key encryption mode that operate like Vernam's one-time pad, and thus permit any number of bytes in the message: XOR ( = KDF(ECDH-secret) xor MSG), and also AES-CTR.  

The problem with Vernam's one-time pad is that without the MAC, then the adversary can XOR any delta into the cipher, to XOR the same delta into the plaintext, which is usually very insecure - unless you have some other security against this.  In ECIES (and many other systems, e.g. TLS), this is not a big problem, because of a MAC detects such tampering.

Since your message is only 8 bytes, you could instead use a 64-bit block cipher.  Here, if adversary can modifies the cipher, the plaintext should become garbled.  (Is this called implicit authentication? See * below)  The SEC1 version of ECIES allows the old TDES-CBC which could work if you are willing to use a very old cipher.  I do not recall whether there are other reputable 64-bit block ciphers.  Did Rijndael have such a variant? Do some of block cipher submitted to the NIST LWC allow 8-byte blocks?

I believe that there are yet other symmetric encryption modes that may help here. For example, the one I remember is Rivest's All-or-Nothing-Transform, or package transform (which is keyless but can be applied prior to modes like CTR), but I do not recall if it can work on 8 byte messages.  I would not be surprised if there were newer, or better, schemes.  

* If I had to name this goal, I would call it implicit authentication, but I would not be surprised if it has been properly formalized under some different name(s), e.g. in AONT research or block cipher research.

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 17:14:12 -0400

> Do both sides have static public keys?  Yes, I should read the DRIP documents ...

This will be a new, exciting (ahem) document.  You have to spend time 
looking at the work done todate on Unmanned Aircraft Tracking by people 
that think they need cybersecurity but don't know how that impacts their 
designs which are already set in regulations...

So you may not want to pollute your mind.  :)

> Anyway, ECIES is for when the recipient has a static PK, but the sender does not.

My situation.  I am even recommending that static PK not be static for 
too long.  PCS protection thoughts.

> I think there are CFRG proposals or work items that extend ECIES to "Hybrid ..." and that add features like mutual authentication, etc.

Here the direct parties:  USS and Operator are already authenticated.  
The 3rd party, the UA is not and will be blasting out private 
information about the Operator that really should be protected (Hey, the 
guy that is controlling me is a block thata way!)  But the Operator 
controls what the UA reveals about the operator, so there is hope if I 
can encrypt the content.  (I try not to confuse about all the different 
channels for communication here)

> * If I had to name this goal, I would call it implicit authentication, but I would not be surprised if it has been properly formalized under some different name(s), e.g. in AONT research or block c…

Dan,

thank you for all this information.

This is not a one-time encryption of a string with a key derived from 2 
PK.  If the operator is mobile, the data is constantly changing and 
messages WILL be lost so both CTR and CFB are in trouble so to speak.

I can start a counter, but which counter value to use for a specific 
received message.  Since these bytes are value only, there is no way to 
check that decrypt worked by seeing a couple bytes having the expected 
content.

ECB would actually be better, as the key is only used for a 'few' blocks 
(4 hr flight, messages every 10s = 1,440 encrypted blocks).

I have just recieved confirmation that the plaintext is going up, most 
likely to 12 bytes in the next iteration of the standard because the FAA 
and EASA want Altitude along with Long and Lat.

Of course that means support 8 bytes in ver 1.0 and 12 bytes in ver 1.1.

I need to burn more brain cells on this one.

3DES-ECB on 8 bytes, but what on 12?  I hope they don't decide on 5 
bytes for alt...

It always seems so simple when you first start out, but then when you 
line up all the real requirements, it gets hard.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 31 Mar 2020 21:42:06 +0000

On 3/31/20, 17:15, "Cfrg on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    > ECIES = Elliptic Curve Integrated Encryption Scheme, a public-key encryption scheme, 
    > i.e. with a functionality similar to RSA-OAEP, and various other PKEs.
    >

No, it is not your case - because (as Dan explained) ECIES increases message size by auth tag, possibly encryption IV, and ephemeral public key of the sender. It's normal use case is messages/files larger than 8 bytes. ;-)

    > Well, ECIES has built-in message expansion, not only from the ECDH part
    > (which you mentioned) but also because it provides integrity, internally via a MAC tag.
    >
    > To avoid message expansion from the MAC, you could truncate the part of the ECIES
    > ciphertext that corresponds to the MAC, but doing so would *modifies* the design
    > of ECIES and thereby introduces potentially serious attack such as chosen ciphertext attacks.

I would not do that without a security analysis.

    > Since your message is only 8 bytes, you could instead use a 64-bit block cipher. 

That is true - a very good idea. I'd be thinking Simon/Speck. Not DES in any case, and not FEAL ;)

I don't think you can rely on shared counter. Your IV/Nonce would have to have explicitly transmitted part.

It doesn't matter all that much how big your plaintext is (within the reasonable constraint of your application - 8, 12, 24, who cares - it's not 2K). It matters a lot how many bytes you can dedicate/allocate for extra crypto (IV, auth tag, etc).

---

From: Henry B Hotz <[email-masked]>
Date: Tue, 31 Mar 2020 14:44:11 -0700

NIST SP800-38G. 

> On Mar 31, 2020, at 12:03 PM, Robert Moskowitz <[email-masked]> wrote:
> 
> 
> 
> I am only marginally familiar with it.  Not something I have had occation to study.
> 
> Thanks.
> 
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 18:02:27 -0400

Uri,

thank you for this.

I will write the draft using Speck for 64 bit block.  That will get the 
draft out and open up for discussion.

I will use ISO 29167-22 for the reference for starters.

And per Dan's comments about ECIES, I should call this a hybrid ECIES.

Thanks all that have helped on this.

And I am open to any other considerations for dealing with this shoehorn 
problem.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 31 Mar 2020 22:56:24 +0000

thank you for this.

My pleasure.

I will write the draft using Speck for 64 bit block.  That will get the draft out and open up for discussion.

This indeed makes sense to me.

It doesn’t matter what you call it. What matters is that you aren’t likely to be able to use it, due to your message size constraints..

And I am open to any other considerations for dealing with this shoehorn problem.

OK, will say more later.

 
    > ECIES = Elliptic Curve Integrated Encryption Scheme, a public-key encryption scheme, 
    > i.e. with a functionality similar to RSA-OAEP, and various other PKEs.
    >
    > Again, it is not clear to me that you are wholly using ECIES. Indeed, it is not exactly what your problem is.
    >
    > Anyway, ECIES is for when the recipient has a static PK, but the sender does not.

 
    > Well, ECIES has built-in message expansion, not only from the ECDH part
    > (which you mentioned) but also because it provides integrity, internally via a MAC tag.
    >
    > To avoid message expansion from the MAC, you could truncate the part of the ECIES
    > ciphertext that corresponds to the MAC, but doing so would *modifies* the design
    > of ECIES and thereby introduces potentially serious attack such as chosen ciphertext attacks.

    > Since your message is only 8 bytes, you could instead use a 64-bit block cipher.

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 31 Mar 2020 19:01:55 -0400

Hi Robert,

Sorry to go offlist.

I worked on a unmanned aerial vehicle program back in 2009 to about
2010 and 2012. I was part of the fix for this for one company:
https://www.wired.com/2009/12/insurgents-intercept-drone-video-in-king-sized-security-breach/

I was also part of the fix for this for one company:
https://www.wired.com/2012/04/iran-drone-hack/.

Something that was not reported in the press... When the US entered
Afghanistan, China entered Iran. China had been performing sigint on
the US for about a decade.

Iran did not [accidentally?] capture a single drone. The US and Israel
were flying illegal missions into Iran for years. China helped Iran
capture about two dozen drones during that period. China used simple
playback attacks to instruct the drones to land.

Be very careful about those playback attacks. Be sure your nonces are
long enough to ensure freshness and avoid collisions.

I can put you in touch with the company. They are located in Alabama.
The program manager is a very nice fellow.

Jeff

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Apr 2020 00:36:19 +0100

On 31/03/2020 23:02, Robert Moskowitz wrote:
> Speck 

Hmm. Were the design criteria for that algorithm
ever published in the end? (I've not followed it,
so they may have been.)

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Mar 2020 23:56:49 +0000

*   I will write the draft using Speck for 64 bit block.  That will get the draft out and open up for discussion.

Simon and speck are controversial, and almost nobody believed that they weren’t deliberately crippled.  It hasn’t been proven.  But there were enough concerns that ISO rejected them.  See https://rwc.iacr.org/2019/slides/RWC87slides.pdf

I mention all this because I am sure using Speck will be controversial, and you need to be sure that you are willing to take on that battle.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 21:01:09 -0400

On 3/31/20 7:56 PM, Salz, Rich wrote:
>
>   * **I will write the draft using Speck for 64 bit block.  That will
>     get the draft out and open up for discussion.
>
> Simon and speck are controversial, and almost nobody believed that 
> they weren’t deliberately crippled.  It hasn’t been proven.  But there 
> were enough concerns that ISO rejected them.  See 
> https://rwc.iacr.org/2019/slides/RWC87slides.pdf
>
> I mention all this because I am sure using Speck will be 
> controversial, and you need to be sure that you are willing to take on 
> that battle.
>

I will look at those slides, as the information I found on the ISO 
standard was 2018.

So far I am using it as a placeholder, as nothing else seems to be 
available.  Put it in a ID, and hopefully alternatives will come forward.

And we all know that placeholders all get replaced before any code gets 
locked in.

Right?

For this limited use, crippled is probably not an issue.

An observer has to be in place to 'see' the broadcast messages. Once 
they hit the USS, they are decrypted and the UTM contains the cleartext 
data forwarded by the USS.  NSA will have authorization into the US 
UTM.  The others, they have to have equipment there to see the 
messages.  And they probably will be into many of those UTM anyway...

If Speck is totally broken and any observer can quickly decrypt the 
content, then this is a non-starter.

Hopefully this will be an opertunity for some good work.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 21:05:50 -0400

> controversial, and you need to be sure that you are willing to take on 

And if I had a 2 byte IV, I could get AES-CTR working to protect 2^16-1 
messages.  More than enough for a mission.

This will be up to ASTM and the regulators with us advising.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Apr 2020 01:10:11 +0000

You’d probably write a draft requiring a 64-bit block cipher, proposing SPECK as one that fits the requirements, both block-size-wise and key-size-wise.

And if I had a 2 byte IV, I could get AES-CTR working to protect 2^16-1 messages.  More than enough for a mission.

In fact, if you have two bytes for crypto expansion – you could do better than CTR.

I don’t even know what ASTM is. ;-)

Count me among those “almost”. 

Also, I wasn’t much impressed by those slides.

Depends on the customer. I’m sure FAA, DOT, or other US govt entity would have no problem with SPECK.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 31 Mar 2020 21:19:54 -0400

On 3/31/20 9:10 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I will write the draft using Speck for 64 bit block.  That will get 
> the draft out and open up for discussion.
>
> You’d probably write a draft requiring a 64-bit block cipher, 
> proposing SPECK as one that fits the requirements, both 
> block-size-wise and key-size-wise.
>

I am wordsmithing this now.  Of course the draft COULD go in tomorrow, 
but then it would be dated Apr 1.  So I will probably wait until Thrusday...

> And if I had a 2 byte IV, I could get AES-CTR working to protect 
> 2^16-1 messages.  More than enough for a mission.
>

I am updating my draft with this approach right now.  I figured it out 
myself.  I am so proud of me.  ;)

> I don’t even know what ASTM is. ;-)

astm.org

The standard for UAS Remote ID and Tracking is F3411-19 and is not only 
referenced by the FAA but also EASA.  It costs $85 to purchase or get 
your ASTM membership for $75.

> would have no problem with SPECK.

But maybe not EASA (not entirely sure EASA is the 'correct' EU agency).  
The two together very much control the world-wide decision process.  Of 
course New Zealand could weigh in.  They manage ~1/6 of the world's 
airspace.

---

From: Björn Haase <[email-masked]>
Date: Wed, 1 Apr 2020 06:49:14 +0000

I fear that you might actually need at least some more bytes of payload in order to get any sound scheme realized.
For preventing replay attacks a 32 bit nonce and a 32 bit authentication tag might have to be considered to form the bare minimum requirement ☹.

We have had a similar problem with the severely size-limited BluetoothLE advertising (broadcast) packets.
One option that we use is segmenting the information by splitting it into several packets. This way reception of two or more separate
packets is needed in order to get the full information.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.