-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek
Sent: Friday, July 24, 2020 5:58 PM
To: cip-dev@...
Subject: Re: [cip-dev] Resource describing the Deby workflow?

Hi!

I'm almost done getting SSL working between the BBB and hawkbit. The
last piece of the puzzle is to get NTP working on the BBB (since I
need valid time to ensure that the server certificate is valid).
Unfortunately, I'm

Notice that in this case SSL is not adding as much security as you think it does.

SSL attempts to protect against active attackers, and those can manipulate NTP easily.

In the past, I read a bit about this topic because NTP seemed to be weak against man-in-the-middle attacks and that could cause problems when updating software:
- the device may not be able to judge correctly whether a certificate is expired or not
- the device may reject updates because it thinks they are older than the current update (when using timestamps)

Both cases would cause the device not being updated (a freeze attack).

[Note] civil infrastructure devices may also use GPS Satellites for time synchronization, or contract private leased lines and set up their own NTP server there. Not perfect but probably there are easier ways to compromise your device.

After some reading, I found out that NTP includes authentication support nowadays (symmetric keys, autokey..) but apparently nobody uses them.
https://tools.ietf.org/html/rfc5906
https://chrony.tuxfamily.org/comparison.html (check NTP authentication)

It seems there is a new standard called Network Time Security (NTS) now.
https://www.rfc-editor.org/rfc/rfc8633.html
https://weberblog.net/network-time-security-strengths-weaknesses/
https://www.infoq.com/news/2019/11/cloudflare-open-source-nts/

Also, during my investigation on software update technology I also found out that TUF (the update framework) and its child UPTANE had a separate Time server to limit the freeze attacks.

There was a nice presentation by Justin Cappos in Japan last year:
https://events19.linuxfoundation.org/wp-content/uploads/2018/07/Uptane-2019-Summer-AGL-event.pdf

Thanks,
Daniel

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Monday, July 27, 2020 8:32 PM
Daniel, Pavel:

Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or any sort of
time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether this is
acceptable or not. Can someone chime in?

It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for ChromiumOS)
https://github.com/ioerror/tlsdate/issues/199
https://chromium.googlesource.com/chromiumos/third_party/tlsdate

There are some packages in Debian
https://packages.debian.org/search?keywords=tlsdate
but not for Buster.

Thanks,
Daniel

Thanks
--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

--

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Monday, July 27, 2020 9:55 PM
To: cip-dev@...
Subject: Re: [cip-dev] The security of NTP

Daniel,

Thanks for pointing that out. Since CIP is reliant on available packages on particular versions of Debian, would the process/workflow then
be to wait for tlsdate to be available in Buster and then pull it into CIP and continue working on this issue? Or, should I just go ahead and try
to get tlsdate incorporated into Buster by following the contribution guidelines in Debian?

That would be something that needs to be decided by the whole CIP project, but I read that tlsdate depends on a timestamp that has been removed on TLS 1.3.
https://www.feistyduck.com/bulletproof-tls-newsletter/issue_54_network_time_security_nts_could_finally_bring_support_for_authenticated_network_time

Personally, I think that CIP should focus on NTS (already included in chrony for example)
https://www.iana.org/assignments/nts/nts.xhtml

Thanks,
Daniel

On Mon, Jul 27, 2020 at 8:41 AM Daniel Sangorrin <daniel.sangorrin@... <mailto:daniel.sangorrin@...> > wrote:



> -----Original Message-----
> From: cip-dev@... <mailto:cip-dev@...> <cip-dev@... <mailto:cip-
dev@...> > On Behalf Of Mohammed Billoo
> Sent: Monday, July 27, 2020 8:32 PM
> Daniel, Pavel:
>
> Thanks for the feedback. Is tlsdate a better alternative (https://github.com/ioerror/tlsdate/)? The only caveat if using tlsdate (or
any sort of
> time mechanism that relies on a "well-known" server) is that an Internet connection is necessary. It isn't obvious to me whether
this is
> acceptable or not. Can someone chime in?

It seems that that project is dead, but there is a fork for ChromiumOS remaining that seems to be well maintained (for
ChromiumOS)
https://github.com/ioerror/tlsdate/issues/199
https://chromium.googlesource.com/chromiumos/third_party/tlsdate

There are some packages in Debian
https://packages.debian.org/search?keywords=tlsdate
but not for Buster.

Thanks,
Daniel



>
> Thanks
> --
> Mohammed Billoo
> MAB Labs, LLC
> www.mab-labs.com <http://www.mab-labs.com>





--

Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com <http://www.mab-labs.com>
201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

--