Het aantal bits in een statisch sleutelbestand is niet de OpenVPN-ciffersterkte

Een scanner of een collega wijst op het aantal bits dat in een statisch OpenVPN-sleutelbestand is afgedrukt en vraagt waarom de tunnel geen cijfer van die grootte gebruikt. De vraag klinkt redelijk, en het antwoord is geen getal: de banner telt opgeslagen sleutelmateriaal, terwijl een cijfer alleen het deel verbruikt dat zijn sleutelgrootte vereist. Die som als een sterkte-instelling behandelen leidt tot bewerkingen die niets veranderen. Het formaat is gebouwd om meer materiaal te bevatten dan welke afzonderlijke algoritme dan ook gebruikt.

Hier worden twee vragen door elkaar gehaald: hoeveel sleutelmateriaal het bestand opslaat, en hoe sterk het onderhandelde cijfer is. Alleen de tweede beschrijft de tunnel.

Wat het getal in de banner werkelijk telt

De container serialiseert cijfermateriaal en HMAC-materiaal als afzonderlijke structuren, en de tweerichtingsvorm bevat twee zulke sets zodat elke richting zijn eigen sleutels kan dragen. De schrijvende code leidt het afgedrukte getal af uit het aantal geserialiseerde structuren, hun grootte en acht bits per byte. Dat is rekenkunde over opslag, niet de bewering dat één cijfer elke opgeslagen byte verbruikt. De kop legt ook een maximale toewijzing van cijfermateriaal vast, zodat een bibliotheekwijziging het formaat niet stil kan verkleinen of vergroten.

Vergelijk dat met een certificaatsleutel, waar het aantal bits wel de grootte van één object beschrijft. Een RSA-sleutel van 4,096 bits en een sleutelbestand waarvan de banner 4,096 bits leest, zijn verschillende artefacten met verschillende taken, en ze als twee instellingen op één knop zetten levert slechte conclusies op.

Twee sleutelsets in één bestand

Elke helft van het bestand levert materiaal voor versleuteling en authenticatie, omdat de modus met vooraf gedeelde sleutel pakketten in beide richtingen met die afzonderlijke stukken beschermt. Het actieve cijfer gebruikt alleen de bytes die zijn sleutelgrootte vereist, en de digest gebruikt zijn eigen uitvoergrootte, daarom komt de bruikbare sterkte uit de opties en niet uit de lengte van het bestand. Het hexadecimale blok verlengen vraagt het geconfigureerde algoritme niet om er meer van te verbruiken. De opmerking met een groter getal bewerken verandert nog minder.

Als je echt een langere sleutel wilt, is de instelling die moet veranderen het cijfer of de digest, en de generator produceert wat de gekozen algoritmen nodig hebben.

Het profiel lezen vertelt je welke modus je hebt

Hetzelfde bestandsformaat dient twee heel verschillende taken, en alleen het profiel zegt welke je hebt. Een oude secret-regel maakt het bestand het enige sleutelmateriaal van de tunnel, terwijl tls-auth of tls-crypt het bescherming van het besturingskanaal naast certificaten maakt. Geen van beide toepassingen maakt er de persoonlijke certificaatsleutel van een client van, hoe vergelijkbaar het blok ook lijkt. Bepaal de optie en de versie voordat je een vervanging genereert, en gebruik de gedocumenteerde generator in plaats van tekens toe te voegen.

Dat onderscheid bepaalt ook de reactie op een blootstelling. Een tls-auth-sleutel die uitlekt, legt de sessiesleutels niet bloot, maar laat een aanvaller wel verkeer in het besturingskanaal injecteren, dus hij moet alsnog worden vervangen. Een uitgelekte secret-sleutel is erger, want dat was het materiaal dat de gegevens zelf beschermde.

Wat een beveiligingsreview moet vastleggen

Leg drie dingen apart vast: de onderhandelde bescherming van het gegevenskanaal, de bescherming van het besturingskanaal en hoe peers zich authenticeren. Een regel als data-ciphers AES-256-GCM beschrijft alleen het eerste, en een rapport dat daar stopt kan niet beantwoorden of het besturingskanaal überhaupt beschermd is. Het statische sleutelbestand hoort in de tweede categorie wanneer het met tls-auth of tls-crypt wordt gebruikt, en in geen van beide wanneer het niet wordt gebruikt. Reviewers die de categorieën verwarren, vragen om een groter sleutelbestand terwijl ze een sterker cijfer willen.

Als het bestand is blootgesteld, roteer en herverdeel het via het goedgekeurde kanaal. Tekens toevoegen aan een gecompromitteerd geheim is geen rotatie, en het laat het blootgestelde materiaal geldig.

Bewaar het rotatieverslag bij het profiel waartoe het behoort. De volgende review zal vragen welke sleutel welke periode beschermde, en de banner zal dat niet beantwoorden.