Gedelegeerde referenties voor TLS

Beëindigen van een TLS verbinding vereist het gebruik van de persoonlijke sleutel van een certificaat. Als gevolg hiervan moet de privésleutel worden opgeslagen op elke server die door een service wordt gebruikt. De bescherming van de geheimhouding van deze private sleutel is van het grootste belang voor de goede werking van een Public Key Infrastructure-schema. Een entiteit die in het bezit is van de privésleutel kan man-in-the-middle-aanvallen uitvoeren voor de rest van de geldigheid van het certificaat. Wanneer een aanvaller een privésleutel compromitteert, wordt meestal het certificaat dat aan deze sleutel is gekoppeld, ingetrokken en wordt een nieuwe uitgegeven. Voor bedrijven die meerdere servers gebruiken, zoals Facebook of

” voor de servers die aangeven dat ze geautoriseerd zijn om de beëindigen TLS verbinding.

“Een beperkt delegatiemechanisme dat een TLS peer om zijn eigen referenties uit te geven binnen het bereik van een certificaat dat is uitgegeven door een externe CA. Met deze inloggegevens kan de ontvanger van de delegatie alleen spreken voor namen die de CA heeft geautoriseerd.

Gedelegeerde referenties zijn ontworpen met het doel de beveiliging te vergroten. Daarom bezitten ze bepaalde eigenschappen, zoals gedefinieerd in het IEFT-concept.

• De maximale geldigheidsduur van een gedelegeerde referentie is zeven (7) dagen om de blootstelling te minimaliseren als de privésleutel is aangetast. De korte geldigheidsperiode betekent niet dat de beveiliging van gedelegeerde referenties licht moet worden opgevat. Maatregelen die zijn genomen om de private sleutel van het eindentiteitscertificaat te beschermen, moeten ook gelden voor de bescherming van DC's. Deze omvatten onder meer bestandssysteemcontroles, fysieke beveiliging en hardwarebeveiligingsmodules. Bovendien mogen gedelegeerde inloggegevens alleen worden gebruikt tussen partijen die een vertrouwensrelatie met elkaar hebben.
• De gedelegeerde referenties zijn: cryptografisch gebonden naar het eindentiteitscertificaat. In het bijzonder wordt de persoonlijke sleutel van het eindentiteitscertificaat gebruikt om de handtekening van de DC te berekenen via een algoritme dat wordt gespecificeerd door de referentie. De handtekening bindt de DC effectief aan de namen van het eindentiteitscertificaat.
• Gedelegeerde referenties worden uitgegeven door de klant, wat veel eenvoudiger is dan het maken van een certificaat dat is ondertekend door een CA. Door de klant uitgegeven certificaten zijn ook nuttig om de service te laten werken, zelfs als de CA een downtime heeft. Ook kunnen organisaties experimenteren met algoritmen die niet officieel worden ondersteund door de CA zonder de beveiliging van het eindentiteitscertificaat in gevaar te brengen. 
• Gedelegeerde geloofsbrieven hebben per definitie een korte geldigheidsduur. Bij het instellen van de levensduur van gedelegeerde referenties moeten servers rekening houden met de scheeftrekking van de clientklok om te voorkomen dat certificaten worden afgewezen. De scheeftrekking van de clientklok is ook belangrijk voor het oorspronkelijke certificaat, maar is cruciaal voor de kortstondige gedelegeerde privésleutel. Zowel aan het begin als aan het einde van de geldigheidsperiode moet rekening worden gehouden met de scheeftrekking van de klok van de klant.
• Er is geen intrekkingsmechanisme voor gedelegeerde referenties. Ze worden ongeldig gemaakt zodra de geldigheidsperiode is verstreken. Intrekking van de persoonlijke sleutel van het eindentiteitscertificaat (dat wordt gebruikt om de gedelegeerde referenties te ondertekenen) trekt echter impliciet de gedelegeerde referentie in. 
• Gedelegeerde inloggegevens zijn ontworpen om te worden gebruikt in TLS 1.3 of later. Er is een bekende kwetsbaarheid wanneer: TLS 1.2-servers ondersteunen RSA-sleuteluitwisseling, waardoor een RSA-handtekening over een willekeurig bericht kan worden vervalst. Stel dat een aanvaller een handtekening kan vervalsen. In dat geval kunnen ze vervalste gedelegeerde inloggegevens aanmaken voor de gehele geldigheidsperiode van het eindentiteitscertificaat. Deze kwetsbaarheid is niet aanwezig in implementaties van: TLS 1.3 of hoger. De kwetsbaarheid heeft ook geen invloed op certificaten met elliptische curve-cryptografie, wat: SSL.com biedt. 
• Organisaties kunnen bestaande geautomatiseerde uitgifte-API's zoals ACME gebruiken voor het leveren van gedelegeerde inloggegevens. In dit geval zijn de gebruikte algoritmen alleen de algoritmen die worden ondersteund door de CA, maar deze praktijk verkleint de kans op sleutelcompromissen. SSL.com onderschrijft deze praktijk. 
• Gedelegeerde referenties kunnen niet opnieuw worden gebruikt in meerdere contexten. Uitgevende partijen berekenen de handtekening met behulp van een contextstring die uniek is voor de beoogde rol (client of server), waardoor het gebruik van dezelfde gedelegeerde referentie voor client- en serverauthenticatie onmogelijk wordt. 

maakt gebruik van ECDSA om de PKI aangeboden aan klanten, gedelegeerde inloggegevens die door onze klanten zijn uitgegeven, zijn niet kwetsbaar voor aanvallen op handtekeningvervalsing, zoals hierboven beschreven.