Figure 4.54: CryptoInterfaces for modeling of the interaction of the Application with the Crypto key slots and crypto certificates

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm des AUTOSAR-Metamodells (M2-Ebene) aus der Adaptive Platform Manifest-Spezifikation (AUTOSAR_AP_TPS_ManifestSpecification).
• Technischer Zweck: Formale Spezifikation von kryptografischen Port-Schnittstellen (CryptoInterface) im Manifest. Das Modell definiert die statischen Zugriffsrechte, Speichereigenschaften, Nutzungsbeschränkungen und Sicherheitsrichtlinien, über die Adaptive Applications via Ports mit den Key Slots und Zertifikaten des Crypto-Stacks (ara::crypto) interagieren.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen und Hierarchien

• PortInterface (abstrakt):
  • Generische Basisklasse des AUTOSAR-Metamodells für alle Schnittstellenbeschreibungen an Software-Ports.
• CryptoInterface (abstrakt):
  • Spezialisierung von PortInterface; fungiert als gemeinsamer Wurzeltyp für kryptografische Schnittstellendefinitionen.
• CryptoCertificateInterface:
  • Konkrete Spezialisierung von CryptoInterface zur Modellierung des Zugriffs auf X.509- bzw. Krypto-Zertifikate.
  • Attribute:
    • isPrivate: Boolean [0..1]: Kennzeichnet, ob das Zertifikat bzw. der assoziierte Schlüssel vertrauliche/private Schlüsselkomponenten enthält.
    • writeAccess: Boolean [0..1]: Steuert Lese- vs. Schreib-/Update-Berechtigung der Applikation auf das Zertifikat.
• CryptoCertificateGroupInterface:
  • Konkrete Spezialisierung von CryptoInterface zur Modellierung des Zugriffs auf Gruppen von Krypto-Zertifikaten (z. B. Zertifikatsketten).
  • Attribute:
    • capacity: PositiveInteger [0..1]: Maximale Kapazität bzw. Anzahl an Zertifikaten in der Gruppe.
• AbstractCryptoKeySlotInterface (abstrakt):
  • Spezialisierung von CryptoInterface; abstrahiert gemeinsame Eigenschaften von kryptografischen Key Slots.
  • Attribute:
    • allocateShadowCopy: Boolean [0..1]: Konfiguriert die Allokation einer Schattenkopie zur Gewährleistung atomarer, ausfallsicherer Schlüsselaktualisierungen (Power-Loss Protection).
    • cryptoAlgId: String [0..1]: Eindeutiger Krypto-Algorithmen-Identifikator (z. B. Algorithmen-Familie/OID), auf den der Slot typgebunden ist.
    • cryptoObjectType: CryptoObjectTypeEnum [0..1]: Spezifiziert den Typ des gespeicherten Objekts (z. B. symmetrischer Schlüssel, privater/öffentlicher Schlüssel).
    • slotType: CryptoKeySlotTypeEnum [0..1]: Speichertyp und Lebenszyklus (z. B. transient im RAM vs. persistent im NVM/HSM-Speicher).
• CryptoKeySlotInterface & CryptoKeySlotClientInterface:
  • Konkrete Spezialisierungen von AbstractCryptoKeySlotInterface.
  • Differenzieren zwischen der allgemeinen/verwaltenden Key-Slot-Schnittstelle (CryptoKeySlotInterface) und der applikationsseitigen Konsumentenschnittstelle (CryptoKeySlotClientInterface) für R-Ports.
• CryptoKeySlotContentAllowedUsage:
  • Ziel einer Komposition von AbstractCryptoKeySlotInterface (+keySlotContentAllowedUsage, Kardinalität 0..*).
  • Attribute:
    • allowedKeyslotUsage: String [0..1]: Restriktion der zulässigen Operationen für den Schlüsselinhalt (z. B. kAllowSignature, kAllowEncryption, kAllowKeyDerivation).
• CryptoKeySlotAllowedModification:
  • Ziel einer Komposition von AbstractCryptoKeySlotInterface (+keySlotAllowedModification, Kardinalität 0..1).
  • Attribute:
    • maxNumberOfAllowedUpdates: PositiveInteger [0..1]: Maximale Anzahl erlaubter Schreibzyklen (Schutz vor NVM-Degradation oder Update-Angriffen).
    • restrictUpdate: Boolean [0..1]: Aktiviert zusätzliche Einschränkungen für Inhaltsaktualisierungen.

3. Dynamisches Verhalten & Sequenzablauf

Als Strukturmodell der M2-Ebene bildet das Diagramm keine direkten Laufzeit-Call-Sequenzen ab. Es definiert jedoch den deterministischen Regelapparat für die ara::crypto-Laufzeitumgebung:

1. Port-Instanziierung & Binding:
   • Beim Start des Prozesses instanziiert die Adaptive Platform Middleware die Ports der Applikation anhand des ExecutionManifest / ServiceInstanceManifest.
   • Ein R-Port mit Typ CryptoKeySlotClientInterface wird über Crypto-Service-Mappings an einen physischen Key Slot des Crypto Providers (z. B. HSM-Treiber, PKCS#11-Backend) gebunden.
2. Access Control & Restriction Enforcement (ara::crypto::keys):
   • Fordert die Applikation über ara::crypto::keys::OpenKeySlot() oder LoadKey() den Schlüssel an, prüft der Crypto-Daemon die statischen Manifest-Eigenschaften:
     • Schreiboperationen werden gegen writeAccess und restrictUpdate validiert.
     • Jeder kryptografische Kontextaufruf (z. B. Sign(), Encrypt()) prüft den geforderten Modus gegen die Liste keySlotContentAllowedUsage. Nicht deklarierte Operationen führen zum Abbruch mit Sicherheitsfehlern (CryptoErrc::kUsageViolation).
3. Schlüssel-Update & Shadow-Copy-Handling:
   • Bei Inhaltsaktualisierungen wird maxNumberOfAllowedUpdates dekrementiert bzw. gegen den Zählerstand validiert.
   • Ist allocateShadowCopy == true, schreibt der Stack den neuen Schlüssel zuerst in den Schattenspeicher und vollzieht anschließend einen atomaren Swap-Vorgang, um Korruption bei Spannungsabfall zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• Standard-Traceability:
  • Erfüllt RS_MANI_00031 (Modellierung von Security-Eigenschaften im Manifest) sowie die formalen Manifest-Regeln TPS_MANI_01467 und TPS_MANI_03254.
• Applikations-Entwicklung (ara::crypto):
  • Principle of Least Privilege: Applikations-Ports müssen typisiert auf CryptoKeySlotClientInterface bzw. Zertifikatsschnittstellen zugreifen. Die Nutzung muss in CryptoKeySlotContentAllowedUsage exakt auf die zwingend benötigten Operationen begrenzt werden.
  • Zertifikatsgruppen: CryptoCertificateGroupInterface erlaubt über das Attribut capacity die Bereitstellung und Bündelung mehrerer Zertifikate (z. B. Zertifikatsketten) über einen gemeinsamen Port.
• Plattform- & Treiber-Konfiguration (Crypto Provider):
  • Codegeneratoren erzeugen aus diesen ARXML-Beschreibungen die Zugriffssteuerungslisten (ACLs) und Speicherallokationstabellen für das zugrunde liegende Sicherheitsmodul.
  • slotType bestimmt direkt die Dimensionierung des NVRAM-Layouts bzw. die Belegung und den Lebenszyklus geschützter Hardware-Key-Slots.