class ara::diag::Authentication

Der Konstruktor initialisiert synchron ein Objekt der Handler-Klasse ara::diag::Authentication zur Abwicklung von Diagnose-Authentifizierungsanfragen an einem Software-Port [SWS_DM_01124]. Der Parameter specifier verweist auf den modellierten PortPrototype, der über ein DiagnosticAuthenticationPortMapping zwingend durch ein DiagnosticAuthenticationInterface typisiert sein muss [SWS_DM_01124]. Über den Parameter concurrencyType wird festgelegt, ob das Framework Methodenaufrufe nebenläufig (kConcurrent) oder nicht-threadsicher (kNotConcurrent) zustellt [SWS_DM_01124].

Da die Funktion als noexcept deklariert ist, werden fehlerhafte Aufrufe nicht über Exceptions gemeldet, sondern lösen Framework-Verletzungen (Violations) aus [SWS_DM_01124]:

• InstanceSpecifierMappingIntegrityViolation: Der Bezeichner kann im Kontext der Executable nicht aufgelöst werden oder referenziert keinen PortPrototype [SWS_DM_01124].
• PortInterfaceMappingViolation: Der referenzierte PortPrototype ist nicht als DiagnosticAuthenticationInterface modelliert [SWS_DM_01124].
• ProcessMappingViolation: Zur Laufzeit wird kein passender modellierter Prozess gefunden [SWS_DM_01124].
• InstanceSpecifierAlreadyInUseViolation: Der InstanceSpecifier wurde im aktuellen Prozess bereits für eine Instanz verwendet [SWS_DM_01124].

Der Konstruktor selbst ist threadsicher und ausnahmesicher (exception safe) [SWS_DM_01124], während der zugehörige Destruktor ~Authentication() als nicht threadsicher spezifiziert ist [SWS_DM_01125]. Unmittelbar nach der Instanziierung werden noch keine Diagnoseanfragen weitergeleitet: Die Anwendung muss erst Offer() aufrufen, um die Weiterleitung für den UDS-Dienst 0x29 (Authentication mit PKI Certificate Exchange, APCE AUTOSAR_AP_SWS_Diagnostics Tab. 4.1 „Limitations of sub-functions of 0x19 ReadDTCInformation“) durch den Diagnostic Manager zu aktivieren [SWS_DM_01130]. Die Zertifikatsvalidierung wird anschließend über VerifyCertificateUnidirectional [SWS_DM_01126], VerifyCertificateBidirectional [SWS_DM_01127] und VerifyOwnership [SWS_DM_01128] abgewickelt. Vor der Objektzerstörung muss die Weiterleitung mit StopOffer() beendet werden [SWS_DM_01131].

Mit der synchronen Methode Offer() der Klasse ara::diag::Authentication ([SWS_DM_01130]) registriert eine Adaptive Application ihren Authentifizierungs-Handler beim Diagnostic Management (DM). Dadurch wird der DM autorisiert und in die Lage versetzt, eingehende Anfragen an diesen Handler weiterzuleiten (AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.1 „Offer“). Die Funktion nimmt keine Übergabeparameter entgegen und signalisiert den Ausgang der Operation über den Rückgabetyp ara::core::Result<void>.

Der Aufruf ist als noexcept deklariert und damit ausnahmesicher ([SWS_DM_01130]). Schlägt die Registrierung fehl, weil der Dienst für diese Instanz bereits zuvor bereitgestellt wurde, wird der spezifische Fehlercode DiagOfferErrc::kAlreadyOffered im Result-Objekt zurückgegeben ([SWS_DM_01130]). Zudem ist die Schnittstelle als not thread-safe spezifiziert; parallele Zugriffe auf derselben Instanz dürfen vermutlich nicht ungeschützt erfolgen und müssen applikationsseitig synchronisiert werden. Frage Q-51ab72e4e72a7351 (offen)

Im Lebenszyklus der Diagnoseverarbeitung korrespondiert Offer() direkt mit der Gegenfunktion StopOffer() ([SWS_DM_01131], AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 „StopOffer“), welche die Weiterleitung von Anfragen wieder beendet. Dieses Muster folgt dem einheitlichen Bereitstellungsansatz diagnostischer Handler, wie er beispielsweise auch bei ara::diag::CommunicationControl::Offer ([SWS_DM_00809]) oder ara::diag::DoIPPowerMode::Offer ([SWS_DM_00735]) Anwendung findet, bei denen Anfragen erst nach explizitem Anbieten durch die Applikation verarbeitet werden können ([SWS_DM_01525]).

Verwendung

Die Methode StopOffer der Klasse ara::diag::Authentication (definiert in ara/diag/authentication.h) deaktiviert die Weiterleitung von Anforderungsnachrichten durch den Diagnostic Manager (DM) an die Instanz [SWS_DM_01131]. Der Aufruf wird synchron ausgeführt, erfordert keine Übergabeparameter und besitzt keinen Rückgabewert AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.2 „StopOffer“.

Fehlerbehandlung und Ausführungssicherheit

Die Funktion ist als ausnahmesicher (noexcept) spezifiziert; spezifische Fehlercodes oder Ausnahmen sind nicht definiert [SWS_DM_01131].

Nebenläufigkeit und Einschränkungen

Die Operation ist ausdrücklich als nicht threadsicher („not thread-safe“) ausgewiesen [SWS_DM_01131]. Konkurrierende Aufrufe an derselben Instanz müssen durch die aufrufende Anwendung synchronisiert werden.

Zusammenspiel und Architekturbezug

Das Entwurfsmuster von StopOffer wird im Adaptive Diagnostic Manager konsistent über verschiedene Services und Handler hinweg verwendet, darunter SecurityAccess [SWS_DM_00767], CommunicationControl [SWS_DM_00810], DownloadService [SWS_DM_00793] sowie EcuResetRequest [SWS_DM_01017]. Obwohl die Benennung an die Dienstbereitstellung in ara::com angelehnt ist, handelt es sich um eine diagnostikspezifische Implementierung AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 „Monitors“. Interpretation: Vor der Deaktivierung mittels StopOffer dürfte die Instanz typischerweise zuvor aktiv Anfragen über eine Bereitstellungsfunktion entgegengenommen haben. Frage Q-da990416e53707ed (offen)

Die rein virtuelle Callback-Methode VerifyCertificateBidirectional der Schnittstelle ara::diag::Authentication ([SWS_DM_01127]) wird vom Diagnostic Server aufgerufen, sobald eine Diagnoseanfrage für den UDS-Dienst 0x29 (Authentication) mit der Subfunktion 0x02 (verifyCertificateBidirectional) eintrifft und die initialen Prüfungen erfolgreich durchlaufen wurden ([SWS_DM_01235], AUTOSAR_AP_SWS_Diagnostics §7.3.2.8.11.3 „Service 0x29 – verifyCertificateBidirectional (0x02)“).

Verwendung und Semantik: Der Server übergibt die Kommunikationskonfiguration sowie die vom Tester empfangenen Zertifikats- und Challenge-Daten über communicationConfiguration, clientCertificate und clientChallenge zusammen mit metaInfo und dem cancellationHandler ([SWS_DM_01127], [SWS_DM_01235]). Die Puffer der Eingabe-Spans bleiben gültig, bis das zurückgegebene ara::core::Future über das zugehörige Promise erfüllt oder der Vorgang abgebrochen wird ([SWS_DM_01127]). Asynchron liefert die Methode ein 4-Tupel bestehend aus Server-Challenge, Server-Zertifikat, berechnetem Proof-of-Ownership und dem Ephemeral Public Key des Servers an den Diagnostic Server zurück ([SWS_DM_01127]).

Abbruch und Nebenläufigkeit: Über den cancellationHandler kann die Anwendung den aktuellen Status mittels IsCanceled pollen oder per SetNotifier eine Benachrichtigungsfunktion für den Verbindungsabbruch registrieren ([SWS_DM_01127]). Die Schnittstelle ist als noexcept definiert und darf bezüglich Anfragen unterschiedlicher Clients reentrant aufgerufen werden ([SWS_DM_01127]). Ob die Implementierung threadsicher sein muss, wird über den im Konstruktor übergebenen ConcurrencyType festgelegt ([SWS_DM_01127]).

Fehlerbehandlung und Zusammenspiel: Im Fehlerfall gibt die Anwendung einen passenden NRC gemäß ISO 14229-1 über DiagUdsNrcErrc zurück; negative Rückgabewerte werden vom Diagnostic Server gesondert verarbeitet ([SWS_DM_01127], [SWS_DM_01236]). Innerhalb der UDS-Authentifizierung ([SWS_DM_01226]) bildet die Konfiguration dieser Subfunktion eine notwendige Voraussetzung, falls DiagnosticProofOfOwnership konfiguriert ist ([SWS_DM_01227], [SWS_DM_01228]).

Die Callback-Methode VerifyCertificateUnidirectional der Klasse ara::diag::Authentication wird von der Diagnostic-Server-Instanz aufgerufen, sobald eine Anfrage für den UDS-Service 0x29 mit der Subfunktion verifyCertificateUnidirectional (0x01) empfangen und erfolgreich vorgeprüft wurde (SWS Diagnostics §7.3.2.8.11.2 „Service 0x29 – verifyCertificateUnidirectional (0x01)“, [SWS_DM_01230]). Sie realisiert die unidirektionale Authentifizierung via PKI-Zertifikatsaustausch gemäß ISO 14229-1 ([SWS_DM_01226]).

Als Parameter werden die Kommunikationskonfiguration (communicationConfiguration), das Client-Zertifikat (clientCertificate) und die Client-Challenge (clientChallenge) sowie Metainformationen und ein CancellationHandler übergeben ([SWS_DM_01126]). Die übergebenen Spans bleiben gültig, bis das zurückgegebene ara::core::Future erfüllt oder die Verarbeitung über den Handler abgebrochen wird. Die Methode liefert asynchron ein Tupel bestehend aus der generierten Server-Challenge und dem ephemeren öffentlichen Schlüssel des Servers zurück ([SWS_DM_01126]).

Tritt bei der Validierung ein Fehler auf, ist das Future mit einem passenden negativen Response-Code (NRC) über DiagUdsNrcErrc zu beenden ([SWS_DM_01126]).

Die Funktion ist als exception safe spezifiziert und darf reentrant für Anfragen unterschiedlicher Diagnose-Clients aufgerufen werden ([SWS_DM_01126]). Die Thread-Sicherheit ist bedingt; ob die Implementierung thread-safe sein muss, bestimmt der im Konstruktor festgelegte ConcurrencyType ([SWS_DM_01126]). Im Gesamtablauf ist die Konfiguration dieser Prüfung zwingende Voraussetzung, falls die Subfunktion DiagnosticProofOfOwnership konfiguriert wird ([SWS_DM_01227]).

Verwendung und Aufrufkontext

Die rein virtuelle Methode VerifyOwnership der Klasse ara::diag::Authentication wird vom Diagnostic Server aufgerufen, sobald eine Authentifizierungsanforderung des UDS-Dienstes 0x29 mit der Subfunktion proofOfOwnership (0x03) empfangen wurde und die vorbereitenden Prüfungen erfolgreich verlaufen sind [SWS_DM_01240]. Aufgabe der Implementierung ist es, den vom Tester übermittelten Eigentumsnachweis (Proof of Ownership) anhand des öffentlichen Schlüssels aus dem zuvor ausgetauschten Client-Zertifikat gegen die erzeugte Server-Challenge zu verifizieren [SWS_DM_01128].

Beim Aufruf übergibt der Diagnostic Server die relevanten kryptografischen Eingabedaten sowie Kontextobjekte AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.3.5 „VerifyOwnership“:

• clientPOWN: Enthält den vom Diagnosetester bereitgestellten Proof of Ownership zur vorangegangenen Server-Challenge.
• clientEphemeralPublicKey: Der ephemere öffentliche Schlüssel des Clients für die Diffie-Hellman-Schlüsselvereinbarung nach ISO 14229-1:2020.
• metaInfo: Metainformationen der aktuellen Diagnoseanforderung.
• cancellationHandler: Ermöglicht das Abfragen eines etwaigen Abbruchs (cancellationHandler.IsCanceled) sowie das Registrieren einer Benachrichtigungsfunktion (cancellationHandler.SetNotifier).

Die Funktion arbeitet asynchron und liefert ein ara::core::Future zurück, das im Erfolgsfall die Session-Key-Informationen als Byte-Vektor bereitstellt [SWS_DM_01128].

Fehlerbehandlung

Kann die Eigentumsprüfung nicht erfolgreich durchgeführt werden, setzt die Anwendung einen passenden negativen UDS-Rückgabewert (NRC) gemäß ISO 14229-1 über DiagUdsNrcErrc in das zurückgegebene Future [SWS_DM_01128]. Gibt die Methode einen solchen definierten Fehlercode zurück, sendet der Diagnostic Server eine Negative Response mit dem entsprechenden NRC an den Client [SWS_DM_01241].

Nebenläufigkeit und Randbedingungen

Die Schnittstelle ist als noexcept definiert. Hinsichtlich der Thread-Sicherheit gilt das Verhalten als bedingt (conditional): Ob die Methode threadsicher implementiert werden muss, wird durch den bei der Konstruktion der Instanz spezifizierten ConcurrencyType festgelegt [SWS_DM_01128]. Für die Puffer clientPOWN und clientEphemeralPublicKey ist sichergestellt, dass deren Speicherbereich gültig bleibt, bis das Promise erfüllt oder die Verarbeitung über den cancellationHandler abgebrochen wird [SWS_DM_01128].

Der virtuelle Destruktor ~Authentication() schließt den Lebenszyklus einer Instanz der Klasse ara::diag::Authentication ab und gibt deren Ressourcen frei [SWS_DM_01125]. Deklariert ist die Methode in der Header-Datei #include "ara/diag/authentication.h" des Moduls Diagnostics AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 „Destructor“.

Die Funktion nimmt keine Parameter entgegen, liefert keinen Rückgabewert und wird beim Abbau des Objekts synchron aufgerufen [SWS_DM_01125]. Durch die Qualifizierung als virtual wird gewährleistet, dass bei polymorpher Löschung über Zeiger oder Referenzen auf Basisklassen auch die Ressourcen abgeleiteter Klassen ordnungsgemäß bereinigt werden.

Hinsichtlich der Fehlerbehandlung ist die Methode als exception safe spezifiziert und trägt den Spezifizierer noexcept [SWS_DM_01125]. Fehler- oder Statuscodes werden nicht zurückgegeben, und es treten garantiert keine C++-Ausnahmen nach außen auf.

Bezüglich der Nebenläufigkeit ist ~Authentication() als not thread-safe eingestuft [SWS_DM_01125]. Die Zerstörung darf daher keinesfalls zeitgleich mit anderen Methodenaufrufen derselben Instanz erfolgen. Interpretation: Die anwendende Applikation dürfte verpflichtet sein, vor der Zerstörung alle laufenden Authentifizierungs- oder Diagnosevorgänge abzuschließen und den Aufruf extern gegen parallele Zugriffe abzusichern. Frage Q-41b1c115c1056759 (offen) Der Destruktor setzt die übergeordnete Anforderung RS_Diag_04251 um AUTOSAR_AP_SWS_Diagnostics §8.3.1.1.1.3 „Destructor“.