NTS-beveiliging voor NTP-tijdsprotocol gestandaardiseerd als RFC 8915

Network Time Protocol

NTP is een client-server protocol dat (via UDP-poort 123) de huidige tijd opvraagt, meestal van een handjevol andere systemen. Via een slim algoritme komt de client dan tot een instelling waarover bij de aanbieders (servers) de meeste overeenstemming bestaat. Het resultaat is een tijdsinstelling met een nauwkeurigheid van (typisch) een paar milliseconden. Hoewel je NTP ook prima kunt inzetten voor peer-to-peer synchronisaties, wordt dit protocol meestal in een hiërarchie gebruikt. Clients synchroniseren hun systeemtijd dus met hoger gelegen ― dat wil zeggen: nauwkeuriger ― NTP-servers. Daarnaast communiceren ze vaak ook nog met peers in hun eigen stratum.

• stratum 0: atoom- en radioklokken

• stratum 1: computersystemen direct gekoppeld aan een (stratum 0) tijdsklok (op een "afstand" van microseconden)

• stratum 2: computersystemen gekoppeld aan stratum 1-systemen

• stratum 3: computersystemen gekoppeld aan stratum 2-systemen

• enzovoort

Hoe dichter je bij stratum 0 zit, des te nauwkeuriger zal je systeemtijd zijn. Elke laag voegt immers meer onnauwkeurigheid toe vanwege de ‘onbekende’ vertraging/asymmetrie van de uitwisseling over het netwerk. De referentie-implementatie ntpd (NTP daemon) is de standaard op veel systemen. Maar op Linux (en dan met name de 'Red Hat'-achtigen) is dat inmiddels chrony, en op OpenBSD is dat al langer OpenNTPD. Daarnaast zijn er nog diverse andere NTP-implementaties beschikbaar of in ontwikkeling.

Oud protocol

NTP is net als DNS een oud protocol. Beide stammen uit de eerste helft van de jaren '80, en beide gaan over UDP, de simpelste, snelste en meest efficiënte pakketdienst op het Internet Protocol. Omdat NTP en DNS hun oorsprong vinden in een tijd dat internet nog vooral een academische (en militaire) aangelegenheid binnen kleine kring was, was veiligheid nooit een standaard onderdeel van het originele protocol. Voor DNS hebben we dat inmiddels opgelost met DNSSEC (voor de authenticiteit en integriteit van DNS-records). En deze jaren lijkt DoH/DoT daar als aanvulling voor de vertrouwelijkheid (van het transport) bij te komen.

Geen beveiligingsopties

De huidige versie 4 van NTP, vastgelegd in RFC 5905, bevat wel beveiligingsmogelijkheden, maar die worden (om goede redenen) maar weinig gebruikt. De eerste mogelijkheid is symmetrische encryptie, maar daarvoor moet je wel eerst een geheime sleutel tussen de betreffende systemen uitwisselen. Bovendien is deze beveiliging gebaseerd op het bewezen onveilige MD5-algoritme, zodat het gebruik ervan wordt afgeraden. Onofficieel alternatief voor MD5 hier is SHA-1, dat ook niet meer veilig is maar nog wel voor dit soort authenticatiemechanismen gebruikt kan worden. Daarnaast is er een asymmetrische authenticatiemethode beschikbaar: Autokey, gedefinieerd in RFC 5906. Maar dat is een problematisch/onveilig protocol dat je echt niet moet gebruiken. Dat betekent dat er tot nu toe eigenlijk geen goede opties waren om NTP te beveiligen. Vandaar dat we voor de veiligheid van NTPv4 nu meestal vertrouwen op een koppeling van de response aan het adres van de server waar de bijbehorende query heen werd gestuurd, tezamen met een timestamp (nonce) van de laatste synchronisatie met die server.

Zwakheden in het NTP-protocol

Kijken we naar traditionele aanvallen op NTP-systemen en problemen met implementaties, dan blijkt misbruik van een (publieke) NTP-dienst (abuse) het meest voor te komen. Dat gebeurt bijvoorbeeld als een specifieke server (ongevraagd) wordt ingesteld door de fabrikant van een IoT-apparaat, of wanneer een access provider dit doet in de modems die hij uitzet bij zijn klanten. Een ander bekend probleem zijn DDoS-amplificatie-aanvallen. Maar in 2015 publiceerden Malhotra e.a. van Boston University een paper waarin ze diverse zwakheden in het NTP-protocol zelf blootlegden. De auteurs lieten zien hoe ze door de systeemtijd te veranderen, konden rommelen met allerlei beveiligingsprotocollen die van de juiste tijd afhankelijk zijn. De publicatie van dit onderzoek was de directe aanleiding voor de implementatie van NTS. En ook hier kunnen we weer parallellen trekken met DNS en DNSSEC: In 2008 liet Dan Kaminksy zien hoe je valse informatie in een caching resolver injecteert. Dat was de aanleiding om serieus met de implementatie van DNSSEC aan de slag te gaan. SIDN Labs en Nederlandse software-ontwikkelaars hebben daar een belangrijke voortrekkersrol in gespeeld. De publicatie van de 'SAD DNS'-aanval eerder deze maand toont nog eens het belang aan van deze structurele oplossing.

De tijdsinstelling en DNS/DNSSEC

In de zomer van 2019 publiceerde dezelfde Aanchal Malhotra samen met de mensen van NLnet Labs (verantwoordelijk voor de ontwikkeling van NSD, Unbound, OpenDNSSEC, Routinator en verschillende andere netwerk-tools) een paper specifiek gericht op het belang van een correcte (veilige) systeemtijd voor DNS. Een belangrijk probleem met NTP is dat deze software op zowel grote als hele kleine internet-connected systemen draait, dat sommige daarvan heel lang draaien, en dat met name IoT-apparaten geen updates ontvangen. Specifiek voor validerende resolvers luidt het advies om NTP aan te zetten, maar dan wel met een goede configuratie. Dat betekent in ieder geval dat deze uitsluitend geconfigureerd mag worden als client, niet als server. Daarnaast zijn de NTP-clients op validerende resolvers de eerste om het hieronder beschreven NTS-protocol te gaan gebruiken. We bespreken de kwetsbaarheden in NTP en DNS zoals die de afgelopen jaren in de publicaties van Malhotra en NLnet Labs naar voren zijn gebracht in dit artikel.

NTS: een relatief complex protocol

NTS beveiligt de authenticiteit en integriteit van NTP-berichten in client-server mode. De ontwerpers zijn bij de ontwikkeling ervan zo dicht mogelijk bij het bestaande NTP-protocol gebleven. Dat betekent dat NTS is opgezet als een uitbreiding van NTP versie 4. Op die manier wordt de snelheid van de UDP-uitwisseling tussen client en server niet aangetast. De netwerkvertraging/asymmetrie bepaalt immers de nauwkeurigheid waarmee de client de juiste tijd kan overnemen van een server. Daardoor is NTS wel een relatief complex protocol geworden: Om te beginnen opent de client (over TCP) een TLS-verbinding met de NTS-server (op poort 4460). Daarbij wordt net als bij andere TLS-gebaseerde internetprotocollen (denk aan HTTPS) eerst een PKI-certificaat(keten) binnengehaald en worden verschillende cryptografische protocollen uitonderhandeld. Vervolgens krijgt de client via dit beveiligde kanaal een of meerdere cookies toegestopt en een IP-adres/UDP-poort-combinatie waarvoor deze geldig zijn, en een (symmetrische) c2s (client-to-server)-sleutel en s2c (server-to-client)-sleutel. Deze uitwisseling (de NTS Key Establishment, NTS-KE) is in principe eenmalig. In de NTP-pakketten wordt het zo verkregen sleutelmateriaal nu ingezet voor wat in de cryptografie Authenticated Encryption with Associated Data (AEAD) heet. Deze techniek laat je niet-versleutelde en wel-versleutelde data combineren in één geauthentiseerd bericht. Daarvoor moesten wel extra velden worden toegevoegd aan de NTP-pakketten.

Berichtenuitwisseling

In zijn NTP-query voegt de client een van de cookies (onversleuteld) toe. Deze fungeert alleen als sessiesleutel waaruit de server de benodigde statusinformatie kan afleiden. Op die manier hoeft de server zelf helemaal geen status voor zijn clients bij te houden. Daarnaast wordt een (onversleutelde) random identifier van minstens 32 bytes meegestuurd. Die fungeert als vervanger van de oude origin timestamp tegen off-path spoofing-aanvallen. De authenticiteit van dit alles wordt verzekerd middels een MAC (Message Authentication Code, enigszins vergelijkbaar met een digitale handtekening) op basis van de geheime c2s-sleutel. De NTP-response van de server bevat een nieuw cookie (nu versleuteld), te gebruiken in de volgende NTP-query. Deze steeds wisselende cookies beschermen de client tegen linkability: krijgt een client een ander IP-adres, dan is deze daarna ook niet meer te identificeren aan de hand van een bekende sessiesleutel. De client kan de meestuurde MAC valideren middels de s2c-sleutel die hij eerder via de TLS-verbinding van de server heeft gekregen. Voor de MAC maakt NTS gebruik van de bestaande NTPv4 uitbreidingsvelden gedefinieerd in RFC 7822. Dezelfde ruimte van 128 bits die ook voor de MD5-gebaseerde symmetrische authenticatie van NTP wordt gebruikt, wordt nu gevuld met de 128-bits AES-CMAC (gedefinieerd in RFC 4493). In dit artikel van Johannes Weber staat een en ander nog eens uitgelegd voorzien van een flink aantal diagrammen.

Bootstrapping

Ook bij de inzet van NTS blijft er een kip-ei (bootstrapping)-probleem bestaan: Bij de initialisatie van een systeem moet de client bij het opzetten van de eerste TLS-verbinding ervan uitgaan dat het aangeboden certificaat geldig is, terwijl deze nog geen goede systeemtijd heeft. Met name kleine, goedkope IoT-apparaatjes hebben geen RTC-klokchip aan boord, en ook geen niet-vluchtig geheugen om de laatste geverifieerde tijd in op te slaan. Dat betekent dat zij na het opstarten bijvoorbeeld beginnen te tellen op 1 januari 1970 (de UNIX epoch). NTS-client software kan de consistentie van de 2 kanalen wel checken door te controleren of de NTP-tijd die binnenkomt ligt binnen de geldigheidsduur van het zojuist gekregen TLS-certificaat. Bovendien mogen clients geen fallback doen naar traditioneel NTP als de NTS-server niet bereikbaar is, want daarmee worden zij kwetsbaar voor MITM-aanvallen. Voor beheerders is het advies om meerdere bronnen (NTP-servers) te gebruiken. Op die manier gebruik je hetzelfde mechanisme om de nauwkeurigheid van de tijd te verbeteren om de betrouwbaarheid van je bronnen te verhogen. Op dit moment wordt NTS ondersteund door chrony en NTPsec. Maar ook op andere fronten wordt aan implementaties gewerkt.

De nationale NTP-dienst van Nederland

Cloudflare is een voortrekker geweest in de ontwikkeling van NTS. Zij hebben vanaf juli vorig jaar een pilot lopen. De kar daar werd getrokken door Aanchal Malhotra, wier onderzoekspapers we hierboven al noemden. Maar ook wij bieden NTS aan als experimenteel onderdeel van onze NTP-server. We beschreven deze dienst in dit artikel bij de introductie ervan. De ambitie is om time.nl door te ontwikkelen tot de nationale NTP-dienst van Nederland. Zit je (netwerktechnisch gesproken) in de buurt van Arnhem, dan nodigen wij je van harte uit om onze NTP- en NTS-server direct te gebruiken (in combinatie met nog een paar andere NTP-servers). Op de website van TimeNL vind je ook informatie om onze NTP-service in je computer in te stellen.