Figure 7.2: Interaction with IAM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Sequenzdiagramm (kombiniert mit statischer Komponenten-/Lifeline-Struktur).
• Technischer Zweck: Spezifikation des Autorisierungs- und Zugriffssteuerungsablaufs (Access Control Workflow) beim Zugriff einer Adaptive Application (AA) auf persistente kryptografische Schlüssel. Es definiert die Rollenteilung zwischen Identity and Access Management (IAM) als Policy Decision Point (PDP) und dem Key Storage Provider (KSP) als Policy Enforcement Point (PEP) innerhalb des Cryptography-Subsystems (ara::crypto).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (with linked Crypto Lib):
  • Ausführender Prozess im User-Space, der gegen die C++-Schnittstellen von ara::crypto linkt.
  • Trägt applikationsspezifische IAM-Capabilities (im Execution/Application Manifest deklariert).
• Functional unit of Key Storage Provider:
  • Funktionale Kernkomponente des Key Storage Providers (KSP, üblicherweise innerhalb des Crypto-Daemons oder eines geschützten Systemdienstes).
  • Verwaltet logische und physische Key-Slots und setzt Zugriffsentscheidungen durch (PEP).
• IAM unit of Key Storage Provider:
  • IAM-Bewertungseinheit (PDP, Bindung an ara::iam), die Zugriffspolicies (Key Access Rulesets aus dem Deployment-Manifest) verwaltet und evaluiert.
• Schnittstellen & Kanäle:
  • Kommunikationskanal AA ↔ KSP: IPC-Grenze zur Übermittlung von Slot-Anfragen und Handle-Rückgaben.
  • Interner Schnittstellenpfad KSP ↔ IAM: Synchroner Kontrollfluss zur Autorisierungsprüfung basierend auf Prozessattributen und Slot-Identifikatoren.

3. Dynamisches Verhalten & Sequenzablauf

1. Access Request (AA → KSP):
   • Die Applikation fordert Zugriff auf einen definierten Key Slot an (Aufruf von KeyStorageProvider::OpenKeySlot() o. ä.).
2. Policy Evaluation Query (KSP → IAM):
   • Die funktionale KSP-Einheit ermittelt die verifizierte Prozessidentität der AA (z. B. UID/PID bzw. Security Token via OS-IPC) und übermittelt Key Slot ID + Identitätsmerkmale an die IAM-Einheit.
3. Access Control Decision (IAM → KSP):
   • Die IAM-Einheit gleicht die Identität und Capabilities der AA gegen die hinterlegten Zugriffsregeln (Policies / Ruleset) für den angeforderten Key Slot ab (z. B. Read, Write, Erase).
   • Rückgabe des Autorisierungsentscheids (Grant / Deny) an den KSP.
4. Handle Provisioning (KSP → AA):
   • Access granted: KSP instanziiert bzw. kapselt die Ressource und liefert ein valides Container-Handle (KeySlot::Uptr) an die AA zurück.
   • Access denied: KSP verwirft die Anfrage und gibt ein Null-Handle bzw. einen entsprechenden Fehlercode zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Fehlerbehandlung im Applikationscode: Aufrufe zur Slot-Öffnung liefern ara::core::Result<KeySlot::Uptr>. Applikationsentwickler müssen Zugriffsverweigerungen explizit über ara::crypto::SecurityErrc::kAccessViolation bzw. kPermissionDenied abfangen; ein ungeprüftes Dereferenzieren führt zum Absturz (nullptr).
• Manifest-Konfiguration: Zugriffsrechte sind statisch über AUTOSAR-Modellierungsmanifeste festzulegen:
  • Crypto Service Certificate/Key Slot Deployment: Definition der Ziel-Slots und deren Zugriffsmodi.
  • IAM Access Rule Profile / Execution Manifest: Explizite Zuweisung der IAM-Capabilities an die Executable der AA. Fehlt die Manifest-Zuordnung, blockiert IAM den Zugriff per Default (Deny by Default).
• Stack- & Plattform-Implementierung: Die Integrität der AA-Identität darf nicht auf Parametern der Applikationsebene basieren. Die funktionale KSP-Einheit muss die Identitätsinformationen zwingend über vertrauenswürdige OS-/IPC-Mechanismen (z. B. Peer-Credentials über UNIX Domain Sockets) auflösen, um Privilegienerweiterungen zu verhindern.