Zusammenfassung

  • Der DigestAlgorithmIdentifier in MacData identifiziert PBMAC1 und trägt KDF und MAC in verschachtelten Parametern.
  • PBKDF2 mit HMAC-SHA-256, ein explizites keyLength und direkt kodierte UTF-8-Passwortbytes bilden die Basis.
  • Die RFCs definieren Syntax und Prüfung, aber weder universelle Unterstützung noch eine Produktzertifizierung oder eine Zusage für jedes Bedrohungsmodell.

Die Integritätsgrenze des PFX ist der MAC über den authSafe-Inhalt. Bei PBMAC1 stehen im DigestAlgorithmIdentifier von MacData zwei getrennte Entscheidungen: die passwortbasierte Schlüsselableitung und das Nachrichtenauthentifizierungsschema. Ein Parser darf diese sicherheitsrelevanten Angaben nicht aus älteren Feldern ableiten oder als bloße Verpackungsdetails behandeln.

Die traditionellen MacData-Felder macSalt und iterations werden bei PBMAC1 ignoriert. RFC 9879 empfiehlt Schreibern dennoch nichtleere und von null verschiedene Werte, damit ältere Implementierungen, die zunächst die alte Feldform prüfen, das Objekt weiterverarbeiten können. Diese Kompatibilitätswerte sind keine aktiven PBMAC1-Eingaben. Wer sie als Salz oder Iterationszahl verwendet, erzeugt eine andere Ableitung.

Vorgeschrieben ist die Unterstützung von PBKDF2 mit HMAC-SHA-256. In den PBKDF2-Parametern muss keyLength ausdrücklich vorhanden sein. Fehlt es, darf der Leser die Verwendung für diesen RFC-Zweck nicht akzeptieren und keinen Wert stillschweigend ergänzen. Das Passwort wird direkt als UTF-8-Bytes kodiert, ohne abschließendes Nullbyte und ohne Byte-Order-Markierung. Das ist nicht die historische PKCS-#12-Passwortdarstellung.

KDF und MAC werden getrennt ausgewählt und geprüft. Algorithmen, Parameter und Schlüssellängen gehören zur Validierung. HMAC-SHA-1 wird nicht empfohlen; Hash-Algorithmen mit höchstens 160 Bit Ausgabe sind für PBMAC1 unzulässig. Abgeleitete Schlüssel unter 20 Oktetten sollten zurückgewiesen werden. Diese Schranken machen ein schwaches Passwort nicht stark und liefern keine Vertraulichkeit; behandelt wird die Integrität.

scrypt darf optional unterstützt werden. Seine Parameter und sein Ressourcenverbrauch müssen dann vor der teuren Ableitung geprüft werden: Speicher, Rechenaufwand, Parallelität und lokale Zeitgrenzen. Die RFCs erklären keinen Kostenwert für jedes Umfeld und belegen nicht, dass eingesetzte PKCS-#12-Implementierungen PBMAC1 unterstützen.

Die Umstellung braucht abgestimmte Schreiber und Leser. Schreiber erzeugen die verschachtelten PBMAC1-Parameter, ein explizites keyLength, direkte UTF-8-Bytes und zulässige Algorithmen. Alte Felder dürfen für Kompatibilität nichtleer bleiben, sind aber keine PBMAC1-Sicherheitseingaben. Leser prüfen zuerst, lehnen fehlende oder schwache Parameter ab und begrenzen den Aufwand. Die Annahme alter Formen braucht ein Ende, nicht nur eine Absicht.

Quellen