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

["Wiethuechter, Adam" <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> 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).
>
> 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.
>
>
> 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.
>
> 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 <[e-mail]>
> wrote:
>
>> 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.
>>
>> 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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tm-rid
>>>
>>
>>
>> --
>> 73's,
>> Adam T. Wiethuechter
>>
>>
>> --
>> Robert Moskowitz
>> Owner
>> HTT Consulting
>> C:      248-219-2059
>> F:      248-968-2824
>> E:      [e-mail]
>>
>> There's no limit to what can be accomplished if it doesn't matter who
>> gets the credit
>>
>
>
> --
> 73's,
> Adam T. Wiethuechter
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      [e-mail]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
>


-- 
73's,
Adam T. Wiethuechter