Re: [Cfrg] Encrypt in place guidance

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

On Tue, Mar 31, 2020 at 2:30 PM Robert Moskowitz
<rgm-sec@htt-consult.com> wrote:
>
> 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.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg