Subject: Re: [Tm-rid] HHIT trust proof for Auth messages

From: "Wiethuechter, Adam" <[email-masked]>
Date: Tue, 1 Oct 2019 12:12:28 -0400

All,

Attached is a mock up of what Bob has here just in the new 0.8 version of
the authentication message.

There is a 23 byte payload limit or 25 bytes if we remove the reserved
bytes and condense. I am unwilling to do this though as then the HHIT or
Trust Timestamp fields would be fragmented across pages. Its already bad
enough that the Trusted Timestamp and standard Timestamp fragment across
the 32 bit boundary (within a page) and worse the signature across 3 whole
pages already. While in practice this probably wouldn't affect much it
makes it harder to understand/read I think.

My concern, is that we are broadcasting over Bluetooth. There are 5 pages
to the authentication message (from my understanding of the new standard).
If we lose any one page it is most likely going to be a signature page (as
it spans 3 whole pages) and there will be no way to achieve that which this
format is intended for without the full signature. Perhaps the payload
section that Bob marked in (and fills the final page of the authentication
message) should be some sort of error correction on the signature?

The second version I think is unattainable in the new format, unless
someone here can defy the laws of physics and make numbers smaller than
they actually are thus allowing more to fit within the 109 byte constrain
of the message format.

Questions, comments, concerns?

On Fri, Sep 27, 2019 at 12:40 PM Robert Moskowitz <[email-masked]>
wrote:

> And here is something I have been working on as condensed proof of HHIT
> ownership objects that can be put into the auth messages.  I have not
> done that yet, like Adam has:
>
>      <figure>
>          <artwork>
>     0                   1 2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    | HHIT                              |
> |                                                               |
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | TIMESTAMP                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    | HHIT                              |
>    | SIG                              |
> .                                                               .
> .                                                               .
> .                                                               .
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    / PAYLOAD                            /
> /                                                               /
>    / +-------------------------------+
>    / |                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    HHIT           16 byte HHIT of EdDSA25519 HI
>    TIMESTAMP      4 byte packet trust until timestamp
>    HHIT SIG       64 byte Signature of whole packet
>    PAYLOAD        0 to n bytes of payload
>        Length     84 + n bytes
>          </artwork>
>      </figure>
>      <figure>
>          <artwork>
>     0                   1 2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    |                            DEV HHIT                           |
> |                                                               |
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | TIMESTAMP                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    |                            DEV HHIT                           |
>    | SIG                              |
> .                                                               .
> .                                                               .
> .                                                               .
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    |                              DEV HI                           |
> |                                                               |
> |                                                               |
> |                                                               |
> |                                                               |
> |                                                               |
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         AUTH TIMESTAMP                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    |                           AUTH HHIT                           |
> |                                                               |
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
>    | AUTH                               |
>    | SIG                              |
> .                                                               .
> .                                                               .
> .                                                               .
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    / PAYLOAD                            /
> /                                                               /
>    / +-------------------------------+
>    / |                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    DEV HHIT       16 byte Dev HHIT of EdDSA25519 HI
>    TIMESTAMP      4 byte packet trust until timestamp
>    DEV HHIT SIG   64 byte Signature of whole packet
>    DEV HI         32 byte Device HI of EdDSA25519 HI
>    AUTH TIMESTAMP 4 byte Dev HHIT trust until timestamp
>    AUTH HHIT      16 byte Authorizer's HHIT of EdDSA25519 HI
>    AUTH SIG       64 byte Signature of Device HHIT-HI
>    PAYLOAD        0 to n bytes of payload
>        Length    200 + n bytes
>          </artwork>
>      </figure>
>
>    |             Type              | Length            |
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Oct 2019 14:41:07 -0400

> message) should be some sort of error correction on the signature?

I think what you have in mind is that you take the 5x25 = 100 bytes, and
did a FEC to get 6x25 pages, such that one can lose any single page.
Each page no longer can ever stand alone now, btw.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Tue, 1 Oct 2019 16:11:46 -0400

Michael,

If you mean 4x23=92 bytes  (pages 0-3 of the auth message) which then
creates 23 bytes of parity; which I use to fill the final page, then yes.
However each time I look at what you wrote I come back with something
different in my head - rather annoying.

I haven't had much exposure to FECs other than seeing them in text and
knowing that it is being used in something; for instance Reed-Solomon,
which I think is a FEC, is used in Tahoe LAFS which I use often. I will
read up on them to get a better idea what you are saying.

-- 
73's,
Adam T. Wiethuechter

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 2 Oct 2019 08:40:06 -0400

Quickly,

We have to find out why the reduction in size when BT5 is 255 bytes and 
the extended messages were designed to work in BT5.

Bob

On 10/1/19 12:12 PM, Wiethuechter, Adam wrote:
> All,
>
> Attached is a mock up of what Bob has here just in the new 0.8 version 
> of the authentication message.
>
> bytes and condense. I am unwilling to do this though as then the HHIT 
> or Trust Timestamp fields would be fragmented across pages. Its 
> already bad enough that the Trusted Timestamp and standard Timestamp 
> fragment across the 32 bit boundary (within a page) and worse the 
> signature across 3 whole pages already. While in practice this 
> probably wouldn't affect much it makes it harder to understand/read I 
> think.
>
> My concern, is that we are broadcasting over Bluetooth. There are 5 
> pages to the authentication message (from my understanding of the new 
> standard). If we lose any one page it is most likely going to be a 
> signature page (as it spans 3 whole pages) and there will be no way to 
> achieve that which this format is intended for without the full 
> signature. Perhaps the payload section that Bob marked in (and fills 
> the final page of the authentication message) should be some sort of 
> error correction on the signature?
>
> someone here can defy the laws of physics and make numbers smaller 
> than they actually are thus allowing more to fit within the 109 byte 
> constrain of the message format.
>
> On Fri, Sep 27, 2019 at 12:40 PM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 2 Oct 2019 16:04:04 -0400

While waiting for Gabriel to answer our emails I have been playing with
Reed-Solomon encoding with the message formats. I assume worst case
scenario of having only 5 pages to play with (the more I examine what I can
access for implementation the more convinced I am that this is the reality
of our situation) and I am using the above format to work out something
(specifically the shorter format as its the only one that fits currently).

The first page has 17 bytes of user data, which is just to HHIT. We can
also obtain this via the Basic ID message so I am not that worried about
loss here.
The next 3 pages contain the trusted timestamp (not terribly important but
useful information) and the HHIT Signature (very important). If we lose any
one of these packets the whole point of authentication is gone. We still
have one page left, that Bob has marked as "payload".

Assuming we want to run Reed-Solomon (and to my knowledge after doing some
internet search to understand it) we want an RS(92,69) with 8 bit symbols.
This will give us 23 bytes of parity that we would place into the "payload"
section and would protect the 3 signature pages from up to 11 errors. This
is assuming the following: RS(n,k) and 2t=n-k where; n=payload size, k=data
size, t=correctable errors. I used [1] as a reference to understand what I
was doing.

Bob, also note that while I know BT5 is an option I am constraining myself
to BT4 for the time being as it is widely available and I don't fully
understand BT5 Extended Message format at this time. I also want to develop
up into BT5 (after getting BT4 formatting in a good state) and not develop
down into BT4.

[1]
https://www.cs.cmu.edu/~guyb/realworld/reedsolomon/reed_solomon_codes.html

On Wed, Oct 2, 2019 at 8:40 AM Robert Moskowitz <[email-masked]>
wrote:

> On Fri, Sep 27, 2019 at 12:40 PM Robert Moskowitz <
> [email-masked]> wrote:
>
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
>

-- 
73's,
Adam T. Wiethuechter

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 2 Oct 2019 16:13:26 -0400

We can do better than that. We are not dealing with random byte errors in
unknown locations but rather the loss of an entire BT frame, the location
of which will be known due to the missing sequence number. Thus one 23 byte
Reed-Solomon check frame can correct for the loss of one 23 byte data frame.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 2 Oct 2019 17:20:02 -0400

On 10/2/19 4:04 PM, Wiethuechter, Adam wrote:
> While waiting for Gabriel to answer our emails I have been playing 
> with Reed-Solomon encoding with the message formats. I assume worst 
> case scenario of having only 5 pages to play with (the more I examine 
> what I can access for implementation the more convinced I am that this 
> is the reality of our situation) and I am using the above format to 
> work out something (specifically the shorter format as its the only 
> one that fits currently).

A supposition is that there were performance/reliability challenges with 
more pages.  Unfortunately, we have a weak connection into the closed 
ATSM wg.

>
> The first page has 17 bytes of user data, which is just to HHIT. We 
> can also obtain this via the Basic ID message so I am not that worried 
> about loss here.

You have the 'MAC' mapping to work with, so if something goes, it is the 
HHIT to save 16 bytes (almost a page).

> The next 3 pages contain the trusted timestamp (not terribly important 
> but useful information) and the HHIT Signature (very important). If we 
> lose any one of these packets the whole point of authentication is 
> gone. We still have one page left, that Bob has marked as "payload".

The trusted timestamp is very important.  More details to follow on what 
this small 'cert' is.

>
> Assuming we want to run Reed-Solomon (and to my knowledge after doing 
> some internet search to understand it) we want an RS(92,69) with 8 bit 
> symbols. This will give us 23 bytes of parity that we would place into 
> the "payload" section and would protect the 3 signature pages from up 
> to 11 errors. This is assuming the following: RS(n,k) and 2t=n-k 
> where; n=payload size, k=data size, t=correctable errors. I used [1] 
> as a reference to understand what I was doing.
>
> Bob, also note that while I know BT5 is an option I am constraining 
> myself to BT4 for the time being as it is widely available and I don't 
> fully understand BT5 Extended Message format at this time. I also want 
> to develop up into BT5 (after getting BT4 formatting in a good state) 
> and not develop down into BT4.

My BT5 comment was wondering why they cut the BT4 down to less than what 
BT5 will deliver.  It makes it a challenge for developing messages that 
work with both.  We definitely have to live within BT4 constraints.  Now 
to find out what they are.

> On Wed, Oct 2, 2019 at 8:40 AM Robert Moskowitz 
>     We have to find out why the reduction in size when BT5 is 255
>     bytes and the extended messages were designed to work in BT5.
>
>     Bob
>
>>     Attached is a mock up of what Bob has here just in the new 0.8
>>     version of the authentication message.
>>
>>     There is a 23 byte payload limit or 25 bytes if we remove the
>>     reserved bytes and condense. I am unwilling to do this though as
>>     then the HHIT or Trust Timestamp fields would be fragmented
>>     across pages. Its already bad enough that the Trusted Timestamp
>>     and standard Timestamp fragment across the 32 bit boundary
>>     (within a page) and worse the signature across 3 whole pages
>>     already. While in practice this probably wouldn't affect much it
>>     My concern, is that we are broadcasting over Bluetooth. There are
>>     5 pages to the authentication message (from my understanding of
>>     the new standard). If we lose any one page it is most likely
>>     going to be a signature page (as it spans 3 whole pages) and
>>     there will be no way to achieve that which this format is
>>     intended for without the full signature. Perhaps the payload
>>     section that Bob marked in (and fills the final page of the
>>     authentication message) should be some sort of error correction
>>     on the signature?
>>
>>     The second version I think is unattainable in the new format,
>>     unless someone here can defy the laws of physics and make numbers
>>     smaller than they actually are thus allowing more to fit within
>>     the 109 byte constrain of the message format.
>>
>>            |                            DEV
>>         HHIT                           |
>>            |                            DEV
>>         HHIT                           |
>>            |                              DEV
>>         HI                           |
>>            |                         AUTH
>>         TIMESTAMP                        |
>>            |                           AUTH
>>         HHIT                           |
>     E: [email-masked] <mailto:[email-masked]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>
>
>
> -- 
> 73's,
> Adam T. Wiethuechter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Oct 2019 17:31:03 -0400

> size, t=correctable errors. I used [1] as a reference to understand what I

That's not enough.
You have to be able to recover from more than 11 errors; but 23 bytes worth
of errors in the form a missing packet.

RAID-4 can do this on a 3:1 basis.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 09:09:00 -0400

> can also obtain this via the Basic ID message so I am not that worried 

I do not want to rely on the Basic ID Message for the HHIT.  It is an 
opening for attacks.  The adversary sends Basic ID Messages with the 
UAS's MAC addr but some other HHIT.  This confuses the ground observer 
on what HHIT to use to verify the signed message.  Better to include the 
16 bytes of the UAS HHIT.

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Thu, 3 Oct 2019 15:46:06 -0400

Bob,

It was never my intention to removed the HHIT from the authentication
message for the reasons you just stated. This was a miscommunication on my
part. It also stemmed from my misunderstanding of FEC in general and how
they work.

Michael,

Stu sat down with me today and gave me a brief explanation of FECs and his
approach he was thinking and pointing out the flaw that you also noticed. I
still need to understand his idea a bit better to get it down in
writing/format but I am getting there.

On a more general note; the ASTM proposed standard I can confirm is 5 pages
long (17 + 23 *4 = 109 bytes). The reasoning behind this and possible paths
forward are still being looked at.

On Thu, Oct 3, 2019 at 9:09 AM Robert Moskowitz <[email-masked]>
wrote:

> opening for attacks.  The adversary sends Basic ID Messages with the UAS's
> MAC addr but some other HHIT.  This confuses the ground observer on what
> HHIT to use to verify the signed message.  Better to include the 16 bytes
> of the UAS HHIT.
>

-- 
73's,
Adam T. Wiethuechter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Oct 2019 18:23:14 -0400

Wiethuechter, Adam <[email-masked]> wrote:
    > On a more general note; the ASTM proposed standard I can confirm is 5
    > pages long (17 + 23 *4 = 109 bytes). The reasoning behind this and
    > possible paths forward are still being looked at.

Are there bytes in the first page that are not under our control, but could
be included in a FEC, such that it really looks like 23*5?  That would be
easier for most algorithms.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Fri, 4 Oct 2019 14:37:53 -0400

Michael,

Yes. The 25 bytes of the Bluetooth payload are available to us as we need
to fill in the valid OpenDroneID message headers ourselves.

-- 
73's,
Adam T. Wiethuechter