Secure Onboard Communication (SecOC)

Die synchrone Funktion SecOC_Init dient der Initialisierung des Moduls SecOC und überführt dieses bei erfolgreichem Abschluss in den Zustand SecOC_INIT [SWS_SecOC_00106]. Der Aufruf erfolgt über die Schnittstelle aus SecOC.h mit der Service-ID 0x01 [SWS_SecOC_00106].

Parameter und Rückgabewerte

• Übergabeparameter: Über den Eingabeparameter config wird ein Zeiger auf eine ausgewählte Konfigurationsstruktur vom Typ SecOC_ConfigType übergeben [SWS_SecOC_00106].
• Rückgabewert: Die Funktion besitzt keinen Rückgabewert (void) [SWS_SecOC_00106].

Nebenläufigkeit und Partitionierung

Die Ausführung von SecOC_Init ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_SecOC_00106].

Besondere Vorgaben gelten für Systeme mit mehreren Partitionen: Ist das Modul SecOC mehreren Partitionen zugeordnet (indem Hauptfunktionen wie SecOC_MainFunction auf Partitionen verteilt werden), kann eine Init-Funktion pro Partition existieren [SWS_SecOC_00106]. Ob eine zentrale Funktion SecOC_Init oder separate Funktionen je Partition bereitgestellt werden, ist implementationsspezifisch [SWS_SecOC_00106]. Werden partitionsspezifische Funktionen angeboten, muss die Implementierung Namenskollisionen verhindern, beispielsweise durch Anhängen eines Suffixes mit dem Kurznamen der jeweiligen EcucPartition [SWS_SecOC_00106].

Verwendung und Semantik

Die synchrone Funktion SecOC_DeInit beendet den Betrieb der sicheren On-Board-Kommunikation im SecOC-Modul und überführt dieses in den Zustand SecOC_UNINIT [SWS_SecOC_00161]. Die Funktion ist in der Header-Datei SecOC.h deklariert und besitzt die Service-ID 0x05 sowie die Signatur void SecOC_DeInit(void) [SWS_SecOC_00161]. Sie verarbeitet weder Eingangs- noch Ausgangsparameter und liefert keinen Rückgabewert [SWS_SecOC_00161].

Pufferbereinigung und Zustandsübergang

Mit dem Aufruf von SecOC_DeInit werden sämtliche im Modul zwischengespeicherten I-PDUs verworfen und aus den Puffern entfernt [SWS_SecOC_00161]. Werden diese Daten nach einem erneuten Start der gesicherten Kommunikation weiterhin benötigt, müssen sie nach einem erneuten Aufruf von SecOC_Init nochmals bezogen werden [SWS_SecOC_00161].

Nebenläufigkeit und Einschränkungen

Für die Ausführung der Deinitialisierung gelten feste Vorgaben und Randbedingungen [SWS_SecOC_00161]:

• Nicht wiedereintrittsfähig: Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert und darf daher nicht nebenläufig ausgeführt werden [SWS_SecOC_00161].
• Reihenfolgebedingungen: Das Modul verbleibt nach dem Aufruf im uninitialisierten Zustand, sodass nachfolgende Kommunikationsdienste zwingend einen erneuten Aufruf von SecOC_Init erfordern [SWS_SecOC_00161].

Verwendung

Die synchrone Service-Funktion SecOC_IfTransmit dient dazu, die Übertragung einer PDU im Modul SecOC anzufordern [SWS_SecOC_00112]. Sie besitzt die Service-ID 0x49 und wird über die Header-Datei SecOC.h deklariert [SWS_SecOC_00112].

Die Funktion erwartet zwei Eingangsparameter [SWS_SecOC_00112]:

• TxPduId: Der Bezeichner der zu übertragenden PDU (Typ PduIdType).
• PduInfoPtr: Ein Zeiger auf eine Struktur vom Typ PduInfoType, welche die Datenlänge sowie Zeiger auf die PDU-Daten und auf Metadaten bereitstellt.

Es existieren weder Ein-/Ausgangs- noch reine Ausgangsparameter [SWS_SecOC_00112].

Rückgabewerte und Fehlerbehandlung

Als synchroner Rückgabewert wird ein Status vom Typ Std_ReturnType zurückgeliefert [SWS_SecOC_00112]:

• E_OK: Die Übertragungsanforderung wurde akzeptiert [SWS_SecOC_00112].
• E_NOT_OK: Die Übertragungsanforderung wurde nicht akzeptiert [SWS_SecOC_00112].

Im Fehlerfall wird das Scheitern der Anforderung unmittelbar durch E_NOT_OK signalisiert; spezifische Fehlercodes für DET oder DEM werden in der Funktionsspezifikation nicht gesondert ausgewiesen [SWS_SecOC_00112].

Nebenläufigkeit und Einschränkungen

Bezüglich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe PDU-ID [SWS_SecOC_00112].

Die synchrone Schnittstelle SecOC_TpTransmit mit der Service-ID 0x53 dient dem Anfordern einer PDU-Übertragung im Modul SecOC und wird über die Header-Datei SecOC.h deklariert [SWS_SecOC_91008]. Sie nimmt die Sendeanforderung entgegen und leitet die weitere Verarbeitung innerhalb des Moduls ein.

Verwendung und Zusammenspiel

Als Eingabeparameter erwartet die Funktion die PDU-Kennung TxPduId sowie den Zeiger PduInfoPtr auf eine Konstante vom Typ PduInfoType, welche Angaben zur PDU-Länge sowie Zeiger auf die Nutzdaten und Metadaten umfasst [SWS_SecOC_91008]. Das funktionale Zusammenspiel wird durch die Konfiguration bestimmt: Ist SecOCPduType auf SECOC_TPPDU konfiguriert, löst der Aufruf von SecOC_TpTransmit die konkrete Sendeoperation für eine Authentic I-PDU aus [SWS_SecOC_00253].

Rückgabewerte und Nebenläufigkeit

Das Ergebnis des Aufrufs wird über Std_ReturnType zurückgegeben: Der Wert E_OK bestätigt, dass die Sendeanforderung erfolgreich akzeptiert wurde, während E_NOT_OK bedeutet, dass die Anforderung abgewiesen wurde [SWS_SecOC_91008]. Bezüglich des Nebenläufigkeitsverhaltens ist die Funktion reentrant für unterschiedliche PDU-Bezeichner implementiert, darf jedoch keinesfalls für dieselbe TxPduId reentrant aufgerufen werden [SWS_SecOC_91008].

Interpretation: Das Abweisen einer Anforderung mit E_NOT_OK dürfte in der Praxis vor allem auf ungültige Zeigerwerte in PduInfoPtr oder auf eine bereits blockierte bzw. laufende Übertragung derselben PDU zurückzuführen sein. Frage Q-4c6165f6330c4bc2 (offen)

Verwendung und Aufrufkontext

Die synchrone Schnittstellenfunktion SecOC_IfCancelTransmit fordert den Abbruch einer laufenden PDU-Übertragung in einem unterlagerten Kommunikationsmodul an [SWS_SecOC_00113]. Sie ist über die Header-Datei SecOC.h deklariert und besitzt die Service-ID 0x4a [SWS_SecOC_00113]. Über den Übergabeparameter TxPduId vom Typ PduIdType wird diejenige PDU übergeben, deren Sendevorgang abgebrochen werden soll [SWS_SecOC_00113]. Zusätzliche Ein- oder Ausgabeparameter existieren nicht [SWS_SecOC_00113].

Rückgabewerte und Ausführung

Das Ergebnis der Stornierungsanforderung wird synchron über den Rückgabewert vom Typ Std_ReturnType an den Aufrufer übermittelt [SWS_SecOC_00113]:

• E_OK: Das unterlagerte Zielmodul hat den Abbruch der PDU-Übertragung erfolgreich ausgeführt [SWS_SecOC_00113].
• E_NOT_OK: Die Abbruchanforderung wurde vom Zielmodul abgewiesen [SWS_SecOC_00113].

Da spezifische Fehlercodes oder Fehlerbenachrichtigungen an Entwicklungs- oder Diagnose-Fehlererfassungen (DET/DEM) für diese Funktion nicht spezifiziert sind, dient ausschließlich der Rückgabewert zur Fehlererkennung [SWS_SecOC_00113].

Nebenläufigkeit und Einschränkungen

Hinsichtlich des parallelen Aufrufs ist SecOC_IfCancelTransmit reentrant für unterschiedliche PDU-Kennungen, jedoch explizit nicht reentrant für dieselbe TxPduId [SWS_SecOC_00113]. Aufrufende Module müssen daher durch geeignete Synchronisation sicherstellen, dass nicht mehrere Instanzen gleichzeitig einen Sendeabbruch für dieselbe PDU anstoßen.

Die synchrone Funktion SecOC_TpCancelTransmit dient dazu, den Abbruch einer laufenden PDU-Übertragung in einem unterlagerten Kommunikationsmodul anzufordern [SWS_SecOC_91009]. Sie ist über die Header-Datei SecOC.h deklariert und besitzt die Service-ID 0x54 [SWS_SecOC_91009].

Als Eingabeparameter wird die Kennung TxPduId vom Typ PduIdType übergeben, welche die abzubrechende Sende-PDU eindeutig identifiziert [SWS_SecOC_91009]. Das Ergebnis der Abbruchanforderung wird synchron über den Rückgabewert vom Typ Std_ReturnType zurückgemeldet [SWS_SecOC_91009]:

• E_OK: Der Abbruch der Übertragung wurde durch das Zielmodul erfolgreich ausgeführt [SWS_SecOC_91009].
• E_NOT_OK: Der Abbruch wurde vom Zielmodul abgewiesen [SWS_SecOC_91009].

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant für unterschiedliche PDU-IDs, jedoch explizit nicht reentrant für dieselbe PDU-ID [SWS_SecOC_91009]. Aufrufer müssen daher sicherstellen, dass parallele Aufrufe mit identischer TxPduId vermieden werden. Da der Payload keine spezifischen Fehlercodes für das Default Error Tracer (DET) oder Diagnostic Event Manager (DEM) vorsieht, dürfte die unmittelbare Fehlerbehandlung im Aufruferkontext primär über die Auswertung des Rückgabewerts E_NOT_OK erfolgen [SWS_SecOC_91009]. Frage Q-c1f907444c4ca270 (offen)

Die synchrone Funktion SecOC_TpCancelReceive dient dazu, den Abbruch eines laufenden Empfangsvorgangs einer PDU in einem unterlagerten Transportprotokoll-Modul anzufordern [SWS_SecOC_91010]. Über den einzigen Eingangsparameter RxPduId wird dem Modul die eindeutige Identifikation der abzubrechenden PDU übergeben [SWS_SecOC_91010].

Rückgabewerte und Ausführung

Die Rückmeldung über den Erfolg der Stornierung erfolgt unmittelbar über den Rückgabewert vom Typ Std_ReturnType [SWS_SecOC_91010]:

• E_OK: Die Stornierung des Empfangs wurde durch das Zielmodul erfolgreich ausgeführt [SWS_SecOC_91010].
• E_NOT_OK: Die Stornierung wurde durch das Zielmodul abgewiesen [SWS_SecOC_91010].

Spezifische Fehlercodes, Entwicklungsfehler (DET) oder Produktionsfehler (DEM) sind in den Spezifikationsdaten der Funktion nicht vorgesehen. Interpretation: Mit dem in der Spezifikation genannten Zielmodul („destination module“) dürfte das unterlagerte Transportprotokoll-Modul gemeint sein, an welches die Abbruchanforderung gerichtet wird. Frage Q-bce6ed77e65a6b9b (offen)

Nebenläufigkeit und Einbindung

Hinsichtlich der Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) deklariert [SWS_SecOC_91010]. Daher darf kein gleichzeitiger oder unterbrechender Aufruf erfolgen; aufrufende Softwareeinheiten müssen Zugriffe entsprechend koordinieren. Die Funktion besitzt die Service-ID 0x4c und wird über die Header-Datei SecOC.h deklariert [SWS_SecOC_91010].

Die synchrone Funktion SecOC_VerifyStatusOverride ermöglicht es der Applikation, das Verifikations- und Weiterleitungsverhalten von SecOC gezielt zu überschreiben, um I-PDUs unabhängig vom tatsächlichen Verifikationsergebnis zu akzeptieren oder zu verwerfen sowie Fehlerbehandlungen zu steuern [SWS_SecOC_00122].

Parameter und Aufrufkontext

Die Adressierung richtet sich nach der Modulkonfiguration: Ist SecOCOverrideStatusWithDataId auf FALSE gesetzt, identifiziert Value ID den Freshness Value aller zugeordneten Secured I-PDUs; steht der Parameter auf TRUE, bezeichnet Value ID direkt die Data ID einer Secured I-PDU [SWS_SecOC_00122]. Über overrideStatus wird das gewünschte Verhalten und dessen zeitliche Gültigkeit definiert. Der Zähler numberOfMessagesToOverride bestimmt die Anzahl sequenziell zu überschreibender Verifikationen, wird jedoch ausschließlich bei den Modi SECOC_OVERRIDE_DROP_UNTIL_LIMIT, SECOC_OVERRIDE_SKIP_UNTIL_LIMIT und SECOC_OVERRIDE_PASS_UNTIL_LIMIT ausgewertet [SWS_SecOC_00122].

Für die Modi SECOC_OVERRIDE_PASS_UNTIL_NOTICE, SECOC_OVERRIDE_SKIP_UNTIL_LIMIT, SECOC_OVERRIDE_PASS_UNTIL_LIMIT und SECOC_OVERRIDE_SKIP_UNTIL_NOTICE muss zwingend SecOCEnableForcedPassOverride auf TRUE konfiguriert sein [SWS_SecOC_00122].

Nebenläufigkeit und Rückgabewerte

Die Funktion ist reentrant für unterschiedliche Freshness Value IDs, aber nicht reentrant für dieselbe Freshness Value ID [SWS_SecOC_00122]. Ein erfolgreicher Aufruf liefert E_OK, während ein fehlgeschlagener Aufruf mit E_NOT_OK quittiert wird [SWS_SecOC_00122].

Zusammenspiel bei der Verifikation

Ein gesetzter Override greift in die Verarbeitungslogik des Empfangspfads ein:

• Werden getrennte Authentic und Cryptographic I-PDUs verwendet (SecOCRxSecuredPduCollection), steuert overrideStatus das Verhalten, sobald beide PDUs mit passendem Message Linker empfangen wurden [SWS_SecOC_00203], [SWS_SecOC_00206], [SWS_SecOC_00211].
• Selbst bei Überschreiten von SecOCAuthenticationBuildAttempts oder SecOCAuthenticationVerifyAttempts sowie bei nicht behebbaren Fehlern (wie KEY_FAILURE) richten sich Verifikationsergebnis und PDU-Weiterleitung vorrangig nach overrideStatus [SWS_SecOC_00240], [SWS_SecOC_00241].

Verwendung

Die synchrone Funktion SecOC_SendDefaultAuthenticationInformation ([SWS_SecOC_91013]) ermöglicht es, das Versenden nicht authentifizierter I-PDUs an untergeordnete Schichten gezielt freizugeben oder zu sperren. Der Dienst ist über SecOC.h deklariert und steuert über das Flag send Default Authentication Information das Verhalten für eine spezifische Freshness Value ID. Bei erfolgreicher Anforderung gibt die Funktion E_OK zurück, andernfalls E_NOT_OK ([SWS_SecOC_91013]).

Zusammenspiel und Fehlerverhalten

Die Funktion ist optional und steht nur zur Verfügung, wenn der Parameter SecOCDefaultAuthenticationInformationPattern konfiguriert ist ([SWS_SecOC_91013]). Das Verhalten greift, wenn die Generierung der Authentifizierungsinformationen fehlschlägt – beispielsweise wenn der Zähler SecOCAuthenticationBuildAttempts erreicht wurde, die Frische-Funktion E_NOT_OK liefert oder die Berechnung des Authentikators einen nicht behebbaren Fehler wie KEY_FAILURE bzw. E_NOT_OK zurückgibt ([SWS_SecOC_91013], [SWS_SecOC_00229]):

• Wurde der Dienst mit TRUE aufgerufen, verwendet das Modul das Muster SecOCDefaultAuthenticationInformationPattern für alle Bytes des Frischewerts und Authentikators, um die Authentifizierungsinformationen aufzubauen, und bricht die Sendeanforderung nicht ab ([SWS_SecOC_91013], [SWS_SecOC_00229]).
• Ist der Dienst nicht verfügbar oder wurde er für die betreffende ID mit FALSE aufgerufen, entfernt das Modul die authentische I-PDU aus seinem internen Puffer und bricht die Übertragung ab ([SWS_SecOC_91013], [SWS_SecOC_00229]).

Nebenläufigkeit

Die Funktion ist für dieselbe Freshness Value ID nicht reentrant, darf jedoch für unterschiedliche IDs reentrant aufgerufen werden ([SWS_SecOC_91013]).

Verwendung und Aufrufkontext

Die synchrone Schnittstellenfunktion SecOC_RxIndication (Service-ID 0x42) wird von einem unterlagerten Kommunikationsschnittstellenmodul aufgerufen, um den Empfang einer PDU an das SecOC-Modul zu melden [SWS_SecOC_00124]. Beim Aufruf identifiziert RxPduId die empfangene PDU, während über PduInfoPtr ein Zeiger auf die PDU-Informationen übergeben wird. Diese Struktur enthält die Nutzdatenlänge SduLength, den Pufferzeiger SduDataPtr sowie zugehörige Metadaten der PDU [SWS_SecOC_00124]. Die Funktion besitzt keinen Rückgabewert und ist über die Header-Datei SecOC.h deklariert [SWS_SecOC_00124].

Fehlerbehandlung und Längenprüfung

Für den Empfang von I-PDUs mit statischer Konfiguration (gesicherte, authentische oder kryptografische I-PDUs mit dem EcuC-Parameter DynamicLength gleich FALSE) gilt eine spezifische Fehlerprüfung: Ist die empfangene Länge kleiner als die konfigurierte Länge, verwirft das SecOC-Modul die I-PDU stillschweigend [SWS_SecOC_00268]. Interpretation: Da die Funktion void zurückgibt, dürften fehlerhafte oder unvollständige I-PDUs ohne Rückmeldung an die aufrufende Schicht verworfen werden. Frage Q-6e9a176383e1983b (offen)

Nebenläufigkeit und Einschränkungen

Die Ausführung von SecOC_RxIndication ist reentrant für Aufrufe mit unterschiedlichen PDU-IDs, jedoch explizit nicht reentrant für dieselbe PDU-ID [SWS_SecOC_00124]. Aufrufende Module müssen daher durch ihre Ablaufsteuerung sicherstellen, dass parallele Aufrufe mit identischer RxPduId unterbunden werden.

Die Funktion SecOC_TpRxIndication dient als Callback-Schnittstelle des Moduls SecOC und wird nach dem Empfang einer I-PDU über die Transport-Protocol-API (TP API) aufgerufen [SWS_SecOC_00125]. Über diese Benachrichtigung erfährt SecOC, ob die Übertragung der I-PDU erfolgreich abgeschlossen wurde oder ein Übertragungsfehler aufgetreten ist [SWS_SecOC_00125].

Die Schnittstelle besitzt folgende Parameter und Eigenschaften gemäß [SWS_SecOC_00125]:

• id (PduIdType): Identifikation der empfangenen I-PDU, für die das Empfangsereignis signalisiert wird.
• result (Std_ReturnType): Ergebnis der PDU-Rezeption, welches anzeigt, ob der Transport erfolgreich war oder fehlschlug.
• Rückgabewert: Keiner (void); die Funktion liefert keinen Statuswert an den Aufrufer zurück.

In Bezug auf die Nebenläufigkeit ist SecOC_TpRxIndication als reentrant (Reentrant) spezifiziert und arbeitet synchron (Synchronous) unter der Service-ID 0x45 [SWS_SecOC_00125]. Die Deklaration wird über die Header-Datei SecOC.h bereitgestellt [SWS_SecOC_00125]. Interpretation: Der Aufruf dürfte typischerweise durch eine transportierende Schicht wie das PduR oder ein TP-Modul ausgelöst werden, sobald der PDU-Datentransfer vollständig abgeschlossen ist. Frage Q-6448356fa3609004 (offen)

Für diese Funktion sind in der Spezifikation keine spezifischen Fehlercodes, DET-Prüfungen oder DEM-Fehlereinträge definiert [SWS_SecOC_00125]. Das Fehlerhandling beschränkt sich auf die Übergabe des Transportresultats über den Parameter result, anhand dessen das Modul SecOC entscheidet, ob die empfangenen Daten weiterverarbeitet oder verworfen werden.

Verwendung und Aufrufkontext

Die Funktion SecOC_TxConfirmation wird von dem unterlagerten Kommunikationsschnittstellenmodul aufgerufen, um dem Modul SecOC die erfolgreiche Übertragung oder das Scheitern des Versands einer PDU synchron zu bestätigen [SWS_SecOC_00126]. Der Dienst besitzt keinen Rückgabewert (void), ist in der Header-Datei SecOC.h deklariert und unter der Service-ID 0x40 geführt [SWS_SecOC_00126].

Die Funktion erwartet zwei Eingangsparameter [SWS_SecOC_00126]:

• TxPduId: Kennung der übertragenen PDU (Typ PduIdType).
• result: Ergebnis der Übertragung (Typ Std_ReturnType) mit den Werten E_OK bei erfolgreicher Übermittlung oder E_NOT_OK bei fehlgeschlagener Übertragung.

Fehlerbehandlung und Nebenläufigkeit

Übertragungsfehler der unteren Schichten werden unmittelbar über das Argument result mit dem Wert E_NOT_OK übergeben [SWS_SecOC_00126]. Bezüglich der Nebenläufigkeit ist der Aufruf für unterschiedliche PDU-IDs reentrant, für dieselbe PDU-ID jedoch als nicht reentrant definiert [SWS_SecOC_00126]. Der konkrete Ausführungskontext dürfte vermutlich auf Task- oder Interrupt-Ebene des unterlagerten Moduls liegen, da die Spezifikation hierzu keine Einschränkung vorsieht. Frage Q-8bb15b92df860fc1 (offen)

Zusammenspiel und Weiterleitung

Wird die Konfiguration SecOCTxSecuredPduCollection verwendet, leitet SecOC die Bestätigung erst an die übergeordnete Schicht weiter, wenn SecOC_TxConfirmation sowohl für die Authentic I-PDU als auch für die Cryptographic I-PDU aufgerufen wurde [SWS_SecOC_00270].

Für den Ergebnisstatus an die obere Schicht gilt dabei eine strikte Bedingung: Der Parameter result des weitergeleiteten Aufrufs ist nur dann E_OK, wenn die Bestätigungen für beide Teil-PDUs jeweils mit E_OK übergeben wurden; andernfalls lautet der Status E_NOT_OK [SWS_SecOC_00270].

Die Funktion SecOC_TpTxConfirmation dient der Bestätigung einer über das Netzwerk übertragenen I-PDU und informiert das SecOC-Modul synchron über den Erfolg oder Misserfolg des Sendevorgangs [SWS_SecOC_00152].

Verwendung und Parameter

Der Aufruf erfolgt nach der physischen Übertragung einer I-PDU auf dem Netzwerk [SWS_SecOC_00152]. Die Schnittstelle ist im Header SecOC.h deklariert und besitzt die Service-ID 0x48 [SWS_SecOC_00152]. Sie nimmt zwei Eingabeparameter entgegen und liefert keinen Rückgabewert (void):

• id (Typ PduIdType): Eindeutige Identifikation der übertragenen I-PDU [SWS_SecOC_00152].
• result (Typ Std_ReturnType): Gibt an, ob die Übertragung auf dem Netzwerk erfolgreich war oder fehlgeschlagen ist [SWS_SecOC_00152].

Nebenläufigkeit und Ausführung

Die Funktion ist laut Spezifikation synchron auszuführen und vollständig reentrant (Reentrant) [SWS_SecOC_00152]. Sie kann somit parallel für unterschiedliche oder dieselben I-PDUs aufgerufen werden, sofern dies der Aufrufkontext erfordert.

Fehlerbehandlung und Zusammenspiel

Spezifische DET- oder DEM-Fehlercodes werden im Payload nicht ausgewiesen. Die Fehlerbehandlung bezüglich der Übertragung erfolgt primär über den übergebenen Statusparameter result, welcher dem Modul mitteilt, ob der Sendevorgang glückte [SWS_SecOC_00152]. Interpretation: Die Funktion dürfte primär als Callback-Schnittstelle für unterlagerte Transportprotokoll-Instanzen dienen, um nach dem Abschluss großer oder fragmentierter Übertragungen den Sendestatus zurückzumelden. Frage Q-a2957406d76ee65f (offen)

Die synchrone Schnittstelle SecOC_TriggerTransmit dient dem Kopieren einer zur Übertragung angeforderten SDU [SWS_SecOC_00127]. Über den Parameter TxPduId wird die SDU adressiert, während PduInfoPtr als Ein- und Ausgabeparameter den Zeiger auf den Zielpuffer (SduDataPtr) sowie Puffergrößenangaben (SduLength) bereitstellt [SWS_SecOC_00127].

Verwendung und Datenübergabe

Innerhalb der Funktion prüft das Modul, ob die bereitzustellenden Daten in die über PduInfoPtr->SduLength gemeldete Puffergröße passen [SWS_SecOC_00127]:

• Passen die Daten hinein, kopiert die Funktion diese in den Puffer PduInfoPtr->SduDataPtr, trägt die tatsächliche Anzahl kopierter Bytes in PduInfoPtr->SduLength ein und gibt E_OK zurück [SWS_SecOC_00127].
• Reicht der Speicherplatz nicht aus, liefert die Funktion E_NOT_OK zurück, ohne den Inhalt von PduInfoPtr zu verändern [SWS_SecOC_00127].

Fehlerbehandlung und Nebenläufigkeit

Wird E_NOT_OK zurückgegeben, wurden keine SDU-Daten kopiert. In diesem Fall darf der Aufrufer PduInfoPtr nicht auswerten oder verwenden, da dieser einen NULL-Zeiger enthalten oder auf ungültige Daten verweisen kann [SWS_SecOC_00127]. Die Funktion ist reentrant für unterschiedliche PDU-IDs, jedoch nicht reentrant für dieselbe TxPduId [SWS_SecOC_00127]. Der Service ist über den Header SecOC.h verfügbar [SWS_SecOC_00127].

Verwendung und Semantik

Die synchrone Funktion SecOC_CopyRxData wird aufgerufen, um empfangene Daten eines I-PDU-Segments (N-PDU) an die obere Schicht zu übergeben [SWS_SecOC_00128]. Jeder Aufruf stellt den jeweils nächsten Teil der I-PDU-Daten bereit [SWS_SecOC_00128]. Der Dienst besitzt die Service-ID 0x44 und ist über die Header-Datei SecOC.h verfügbar [SWS_SecOC_00128].

Parameter und Pufferabfrage

Der Parameter id identifiziert die empfangene I-PDU eindeutig [SWS_SecOC_00128]. Über den Zeiger info werden der Quellpuffer SduDataPtr und die Anzahl der zu kopierenden Bytes SduLength bereitgestellt [SWS_SecOC_00128]. Eine Übergabe von SduLength mit dem Wert 0 dient der Abfrage des aktuell im oberen Modul verfügbaren Empfangspuffers; in diesem Fall darf SduDataPtr als NULL_PTR übergeben werden [SWS_SecOC_00128]. An die durch bufferSizePtr referenzierte Stelle wird nach dem Kopieren die verbleibende Puffergröße geschrieben [SWS_SecOC_00128].

Rückgabewerte und Nebenläufigkeit

Die Funktion gibt den Status BufReq_ReturnType zurück [SWS_SecOC_00128]. Bei erfolgreichem Datentransfer meldet sie BUFREQ_OK [SWS_SecOC_00128]. Tritt ein Fehler auf, werden keine Daten kopiert und die Funktion gibt BUFREQ_E_NOT_OK zurück [SWS_SecOC_00128]. SecOC_CopyRxData ist als reentrant spezifiziert [SWS_SecOC_00128].

Verwendung und Semantik

Die synchrone und reentrante Funktion SecOC_CopyTxData wird aufgerufen, um Sendedaten für ein I-PDU-Segment (N-PDU) abzurufen [SWS_SecOC_00129]. Über den Parameter info werden der Zielpuffer SduDataPtr sowie die anzufordernde Bytemenge SduLength übergeben [SWS_SecOC_00129]. Ein Aufruf mit SduLength gleich 0 ermöglicht das Abfragen der verfügbaren Datenmenge oder das Melden von Statusänderungen über den Parameter retry; in diesem Fall darf SduDataPtr ein NULL_PTR sein [SWS_SecOC_00129]. Über availableDataPtr meldet das Modul die verbleibende Restdatenmenge im Sendepuffer zurück [SWS_SecOC_00129].

Wiederholung und Fehlerbehandlung

Das Puffer- und Wiederholungsverhalten wird über retry gesteuert [SWS_SecOC_00129]:

• Ist retry ein NULL_PTR, dürfen kopierte Daten unmittelbar freigegeben werden [SWS_SecOC_00129].
• Bei TP_CONFPENDING verbleiben zuvor kopierte Daten für eine Fehlerbehebung im Puffer [SWS_SecOC_00129].
• TP_DATACONF bestätigt alle vor diesem Aufruf übertragenen Daten zur Pufferfreigabe [SWS_SecOC_00129].
• TP_DATARETRY veranlasst das erneute Kopieren bereits übertragener Daten ab dem durch TxTpDataCnt definierten Byte-Offset [SWS_SecOC_00129].

Als Rückgabewerte liefert die Funktion BUFREQ_OK bei erfolgreichem Kopiervorgang, BUFREQ_E_BUSY, falls temporär nicht genügend Sendedaten bereitstehen (wodurch der Aufrufer den Versuch später wiederholen kann), oder BUFREQ_E_NOT_OK bei generellem Fehlschlag [SWS_SecOC_00129].

Nebenläufigkeit

Die Funktion ist reentrant ausgelegt, sodass parallele Aufrufe für unterschiedliche PDU-Instanzen zulässig sein dürften [SWS_SecOC_00129]. Frage Q-6420f2ca317efcb4 (offen)

Verwendung

Die synchrone und reentrante Funktion SecOC_StartReception wird zu Beginn des Empfangs einer N-SDU aufgerufen, um die Verbindung zu prüfen und den nötigen Empfangspuffer bereitzustellen [SWS_SecOC_00130]. Die N-SDU kann dabei als Einzelframe (Single Frame, SF) oder fragmentiert über mehrere N-PDUs (First Frame, FF, gefolgt von Consecutive Frames, CF) empfangen werden [SWS_SecOC_00130]. Die Deklaration ist über den Header SecOC.h verfügbar [SWS_SecOC_00130].

Parameter und Pufferabfrage

• id: Identifikation der empfangenen I-PDU [SWS_SecOC_00130].
• info: Zeiger auf eine PduInfoType-Struktur mit den Nutzdaten des ersten bzw. einzelnen Frames sowie Metadaten; stehen weder Daten noch Metadaten zur Verfügung, wird NULL_PTR übergeben [SWS_SecOC_00130].
• TpSduLength: Gesamtlänge der zu empfangenden N-SDU. Wird der Parameter mit dem Wert 0 übergeben, liefert der Dienst die aktuell maximal verfügbare Puffergröße zurück [SWS_SecOC_00130].
• bufferSizePtr: Ausgabeparameter für den verfügbaren Empfangspuffer, der vom Transportprotokollmodul zur Berechnung der Block Size (BS) herangezogen wird [SWS_SecOC_00130].

Rückgabewerte und Fehlerbehandlung

• BUFREQ_OK: Die Verbindung wurde akzeptiert und der Empfang wird fortgesetzt; bufferSizePtr weist die verfügbare Puffergröße aus (ist kein Puffer der geforderten Größe verfügbar, wird 0 gemeldet) [SWS_SecOC_00130].
• BUFREQ_E_NOT_OK: Die Verbindung wurde abgewiesen und der Empfang wird abgebrochen; bufferSizePtr bleibt unverändert [SWS_SecOC_00130].
• BUFREQ_E_OVFL: Es kann kein Puffer in der geforderten Länge bereitgestellt werden; der Empfang bricht ab und bufferSizePtr bleibt unverändert [SWS_SecOC_00130].

Die synchrone Schnittstellenfunktion SecOC_GetRxFreshness dient dem Modul SecOC dazu, den aktuellen Freshness-Wert für eine empfangene gesicherte I-PDU abzufragen [SWS_SecOC_91007]. Der Aufruf erfolgt, sobald die gesicherte PDU vollständig empfangen wurde und für deren Konfiguration SecOCQueryFreshnessValue == CFUNC sowie SecOCUseAuthDataFreshness == FALSE festgelegt ist [SWS_SecOC_00247], [SWS_SecOC_00250].

Die Funktion ist reentrant [SWS_SecOC_91007] und übergibt bzw. erwartet folgende Parameter:

• SecOCFreshnessValueID: Kennung des abzufragenden Freshness-Werts [SWS_SecOC_91007].
• SecOCTruncatedFreshnessValue und SecOCTruncatedFreshnessValueLength: Zeiger auf den in der empfangenen PDU enthaltenen gekürzten Freshness-Wert und dessen Länge in Bits [SWS_SecOC_91007].
• SecOCAuthVerifyAttempts: Anzahl der bisherigen Verifikationsversuche seit dem PDU-Empfang (beginnend mit 0, inkrementiert bei jedem Fehlversuch) [SWS_SecOC_91007].
• SecOCFreshnessValue und SecOCFreshnessValueLength: Ausgabepuffer für den ermittelten Freshness-Wert sowie Ein-/Ausgabeparameter für dessen Bitlänge [SWS_SecOC_91007].

Das Ergebnis der Abfrage steuert die weitere Verarbeitung im SecOC:

• E_OK: Der Freshness-Wert wurde erfolgreich bereitgestellt und wird für die Authentifikator-Berechnung genutzt [SWS_SecOC_91007].
• E_NOT_OK: Die Bereitstellung ist aufgrund allgemeiner Probleme oder einer fehlerhaften Freshness-ID fehlgeschlagen [SWS_SecOC_91007].
• E_BUSY: Die Information ist vorübergehend nicht verfügbar [SWS_SecOC_91007]. In diesem Fall inkrementiert SecOC den Authentication-Build-Counter und führt keinen Versuch zur Authentifizierungsverifikation durch [SWS_SecOC_00236].

Die synchrone und reentrante Funktion SecOC_GetRxFreshnessAuthData wird vom SecOC-Modul aufgerufen, um bei vollständig empfangenen gesicherten I-PDUs den aktuellen Freshness-Wert für die Authentifizierung zu ermitteln ([SWS_SecOC_91006], [SWS_SecOC_00246]). Der Aufruf erfolgt spezifisch dann, wenn für die jeweilige PDU-Konfiguration SecOCQueryFreshnessValue = CFUNC sowie SecOCUseAuthDataFreshness = TRUE parametriert sind ([SWS_SecOC_00246], [SWS_SecOC_00249]).

Parameter und Übergabewerte

• Eingangsdaten: Übergeben werden die Kennung SecOCFreshnessValueID, der in der I-PDU enthaltene verkürzte Freshness-Wert SecOCTruncatedFreshnessValue samt Bit-Länge SecOCTruncatedFreshnessValueLength sowie der Zähler SecOCAuthVerifyAttempts, welcher bei Fehlversuchen inkrementiert wird ([SWS_SecOC_91006]).
• Authentifizierungsdaten: Über SecOCAuthDataFreshnessValue und SecOCAuthDataFreshnessValueLength wird optional ein konfigurierter Ausschnitt der empfangenen PDU übergeben; Startposition und Länge werden durch SecOCAuthDataFreshnessStartPosition und SecOCAuthDataFreshnessLen bestimmt ([SWS_SecOC_91006], [SWS_SecOC_00246]).
• Ergebnisdaten: Der vollständige Freshness-Wert wird über den Ausgabepuffer SecOCFreshnessValue bereitgestellt, dessen Bit-Länge als Inout-Parameter SecOCFreshnessValueLength fungiert ([SWS_SecOC_91006]).

Rückgabewerte und Fehlerbehandlung

Die Funktion signalisiert den Erfolg der Abfrage mit E_OK ([SWS_SecOC_91006]). Kann der Freshness-Wert aufgrund genereller Probleme oder einer ungültigen Freshness-ID nicht bereitgestellt werden, gibt sie E_NOT_OK zurück; bei vorübergehender Nichtverfügbarkeit liefert sie E_BUSY ([SWS_SecOC_91006]). Interpretation: Da die Funktion als C-Funktion über CFUNC angebunden wird, dürfte die Implementierung durch ein externes Freshness-Management-Modul erfolgen. Frage Q-01aa77b7235b9001 (offen)

Die synchrone und reentrante Funktion SecOC_GetTxFreshness dient der Bereitstellung des aktuellen Freshness-Werts für zu sendende Nachrichten und ist über den Header SecOC.h deklariert [SWS_SecOC_91004]. Gemäß [SWS_SecOC_00231] ruft das SecOC-Modul diese Funktion für eine PDU auf, wenn in der Konfiguration SecOCQueryFreshnessValue = CFUNC sowie SecOCProvideTxTruncatedFreshnessValue = FALSE gesetzt sind. Interpretation: Da SecOC den Aufruf bei entsprechender Konfiguration ausführt, dürfte die Funktion als Callout durch eine externe Komponente bereitgestellt werden müssen. Frage Q-99a14f896ffddf5f (offen)

Die Schnittstelle verwendet folgende Parameter [SWS_SecOC_91004]:

• SecOCFreshnessValueID (In): Numerische Kennung des angeforderten Freshness-Werts.
• SecOCFreshnessValueLength (InOut): Übergibt bzw. übernimmt die Bitlänge des bereitgestellten Freshness-Werts.
• SecOCFreshnessValue (Out): Zeiger auf das Byte-Array zur Aufnahme des Freshness-Werts im Big-Endian-Format, beginnend mit den höchstwertigen Bits im ersten Byte.

Der Rückgabewert vom Typ Std_ReturnType signalisiert das Ergebnis der Bereitstellung [SWS_SecOC_91004]:

• E_OK: Der Freshness-Wert wurde erfolgreich bereitgestellt.
• E_BUSY: Die Freshness-Information kann temporär nicht geliefert werden.
• E_NOT_OK: Die Anfrage ist fehlgeschlagen, da für die ID oder generell kein Wert ermittelt werden kann.

Die synchrone und reentrante Funktion SecOC_GetTxFreshnessTruncData wird vom Modul SecOC aufgerufen, um bei Sendevorgängen (TX) sowohl den vollständigen Freshness-Wert als auch den gekürzten Freshness-Wert (Truncated Freshness) für das zu übertragende Secured I-PDU abzufragen [SWS_SecOC_91003]. Der Aufruf erfolgt spezifisch dann, wenn für die PDU-Konfiguration SecOCQueryFreshnessValue = CFUNC sowie SecOCProvideTxTruncatedFreshnessValue = TRUE gesetzt sind [SWS_SecOC_00230].

Die Schnittstelle übergibt folgende Parameter [SWS_SecOC_91003]:

• SecOCFreshnessValueID (in): Identifikator des angeforderten Freshness-Werts.
• SecOCFreshnessValue (out): Zielpuffer für den aktuellen vollständigen Freshness-Wert.
• SecOCFreshnessValueLength (inout): Gibt die Länge des bereitgestellten Freshness-Werts in Bits an.
• SecOCTruncatedFreshnessValue (out): Optionaler Puffer für den gekürzten Freshness-Wert, der in die Secured I-PDU eingebettet wird.
• SecOCTruncatedFreshnessValueLength (inout): Übergibt die konfigurierte Länge der gekürzten Freshness; der Wert kann bei Bedarf durch die Funktion angepasst oder unverändert beibehalten werden.

Als Rückgabewert liefert die Funktion E_OK bei erfolgreicher Bereitstellung, E_BUSY, falls die Information temporär nicht verfügbar ist, oder E_NOT_OK, wenn die Bereitstellung aufgrund genereller Probleme oder spezifisch für die übergebene ID fehlschlägt [SWS_SecOC_91003]. Die Deklaration ist über den Header SecOC.h verfügbar [SWS_SecOC_91003].

Verwendung

Die synchrone Funktionsschnittstelle SecOC_SPduTxConfirmation wird vom Modul SecOC genutzt, um anzuzeigen, dass die Übertragung einer gesicherten I-PDU (Secured I-PDU) initiiert wurde [SWS_SecOC_91005]. Die Funktion ist in der Header-Datei SecOC.h deklariert und besitzt keinen Rückgabewert (void) [SWS_SecOC_91005].

Als einziger Übergabeparameter wird SecOCFreshnessValueID als Eingabewert (in) vom Typ uint16 übergeben [SWS_SecOC_91005]. Dieser Parameter transportiert die Kennung des jeweiligen Freshness-Werts für die betroffene I-PDU [SWS_SecOC_91005]. Weitere Ein-, Ausgabe- oder Durchgangsparameter (inout/out) sind in der Schnittstelle nicht vorhanden [SWS_SecOC_91005].

Nebenläufigkeit und Eigenschaften

Die Schnittstelle besitzt die Service-ID 0x4d, arbeitet synchron und ist vollständig reentrant ausgelegt [SWS_SecOC_91005]. Die Eigenschaft der Reentranz gestattet den parallelen Aufruf in nebenläufigen Ausführungskontexten [SWS_SecOC_91005]. Fehlermeldungen über DET oder DEM sowie spezielle Fehlercodes sind in der Schnittstellenspezifikation nicht vorgesehen [SWS_SecOC_91005].

Interpretation: Da SecOC diese Funktion aufruft, um das Starten der PDU-Übertragung zu melden, und dabei ausschließlich die SecOCFreshnessValueID übergibt, dürfte der Aufruf vermutlich der Fortschreibung oder Bestätigung des Freshness-Zählers in einer externen Komponente dienen [SWS_SecOC_91005]. Frage Q-f234a3c6e9b16362 (offen)

Verwendung und Aufrufkontext

Die Funktion SecOC_MainFunctionRx übernimmt die zentrale Authentifizierungs- und Verifikationsverarbeitung des Moduls SecOC für eingehende Nachrichten im Empfangspfad [SWS_SecOC_00171]. Gemäß ihrer Schnittstellenspezifikation besitzt die Funktion die Signatur void SecOC_MainFunctionRx (void), weist die Service-ID 0x06 auf, erwartet keine Übergabeparameter und liefert keinen Rückgabewert zurück [SWS_SecOC_00171]. Sie wird über die Header-Datei SchM_SecOC.h deklariert [SWS_SecOC_00171]; daraus lässt sich ableiten (Interpretation), dass ihr Aufruf periodisch durch den BSW-Scheduler im Kontext eines Betriebssystem-Tasks erfolgt. Frage Q-d24cb58f541f6674 (offen)

Instanziierung und Konfiguration

In Systemkonfigurationen mit mehreren Empfangsinstanzen wird pro konfiguriertem SecOCMainFunctionRx-Container eine eigene Funktionsinstanz nach dem Schema SecOC_MainFunctionRx_<shortName> implementiert [SWS_SecOC_00171]. Dabei entspricht <shortName> dem im ECU-Konfigurationsmodell vergebenen Kurznamen des Containers [SWS_SecOC_00171]. Dies ermöglicht vermutlich eine getrennte zeitliche Steuerung oder Priorisierung unterschiedlicher Rx-Verarbeitungspfade. Frage Q-ebb55c5d3a3da97d (offen)

Fehlerbehandlung und Nebenläufigkeit

Für SecOC_MainFunctionRx sind in den Vorgaben weder spezifische Rückgabewerte noch explizite Fehlercodes für DET oder DEM dokumentiert [SWS_SecOC_00171]. Fehlerzustände oder fehlgeschlagene Verifikationen dürften daher rein intern verarbeitet und asynchron über den Empfangspfad an übergeordnete Module gemeldet werden. Frage Q-5d1e45f7a779bea9 (offen)

Verwendung und Aufrufkontext

Die Hauptfunktion SecOC_MainFunctionTx übernimmt gemäß [SWS_SecOC_00176] die Authentifizierungs- und Verifikationsverarbeitung des SecOC-Moduls auf dem Sendepfad (Tx-Pfad). Sie besitzt die Signatur void SecOC_MainFunctionTx(void), nimmt somit keine Übergabeparameter entgegen und liefert keinen Rückgabewert zurück; ihr ist die Service-ID 0x03 zugeordnet [SWS_SecOC_00176]. Die Deklaration wird über den Header SchM_SecOC.h bereitgestellt [SWS_SecOC_00176]. Interpretation: Da die Einbindung über den Schedule-Manager erfolgt, dürfte der Aufruf typischerweise zyklisch durch den BSW-Scheduler im Kontext einer Betriebssystem-Task stattfinden. Frage Q-34b30208648c8e30 (offen)

Instanziierung und Namenskonvention

Die Spezifikation sieht eine instanzspezifische Umsetzung für Mehrfachkonfigurationen vor: Für jeden konfigurierten Instanz-Container SecOCMainFunctionTx in der ECU-Konfiguration ist genau eine Funktion nach dem Namensschema SecOC_MainFunctionTx_<shortName> zu implementieren, wobei <shortName> dem Kurznamen des betreffenden Konfigurationscontainers entspricht [SWS_SecOC_00176].

Einschränkungen und Fehlerbehandlung

Spezifische Fehlercodes, DET- oder DEM-Rückmeldungen sowie Details zur Reentranz sind im Spezifikationselement nicht separat aufgeführt [SWS_SecOC_00176]. Interpretation: Aufgrund der Kopplung an instanzspezifische Konfigurationscontainer dürfte jede erzeugte Instanz für eine isolierte Teilmenge von Tx-PDU-Verarbeitungen zuständig sein und sollte planmäßig nicht nebenläufig durch denselben Taskkontext unterbrochen werden. Frage (offen)

Die synchrone Callout-Funktion SecOC_VerificationStatusCallout dient der Weitergabe des Status von Verifizierungsversuchen aus dem SecOC-Modul an externe Softwaremodule [SWS_SecOC_00119]. Sie ist über den Header SecOC_Externals.h deklariert und besitzt die Service-ID 0x50 [SWS_SecOC_00119]. Über den Eingabeparameter verificationStatus (Typ SecOC_VerificationStatusType) wird eine Datenstruktur übergeben, die das Verifizierungsergebnis für eine spezifische Freshness Value ID und Data ID bündelt [SWS_SecOC_00119]. Die Funktion besitzt keine Ausgabeparameter und keinen Rückgabewert (Rückgabetyp void) [SWS_SecOC_00119].

Das Verhalten der Statusweiterleitung ist konfigurierbar und unterstützt drei Ausprägungen [SWS_SecOC_00119]:

• Only: Es werden ausschließlich fehlgeschlagene Verifizierungsversuche („False“) propagiert.
• Both: Sowohl erfolgreiche („True“) als auch fehlerhafte („False“) Verifizierungsstatus werden an Module weitergeleitet.
• None: Es wird kein Verifizierungsstatus weitergegeben.

Hinsichtlich der Nebenläufigkeit ist SecOC_VerificationStatusCallout reentrant für unterschiedliche Freshness Value IDs, jedoch nicht reentrant für dieselbe Freshness Value ID [SWS_SecOC_00119]. Implementierende Module müssen daher sicherstellen, dass bei identischer Freshness Value ID keine konkurrierenden Aufrufe stattfinden. Der Aufrufkontext dürfte synchron im Rahmen der internen Verifizierungsroutine des SecOC-Moduls liegen. Frage Q-cd6928ca22d48f54 (offen) Spezifische Fehlercodes oder Meldungen an DET und DEM sind für diesen Callout nicht definiert [SWS_SecOC_00119].

Verwendung und Semantik

Die synchrone Funktion SecOC_VerifyStatus informiert die Applikation über das Ergebnis des Verifikationsversuchs einer empfangenen PDU durch das Modul SecOC [SWS_SecOC_91014]. Die Schnittstelle besitzt die Service-ID 0x53, gibt keinen Wert zurück (void) und wird über den Header SecOC_Externals.h bereitgestellt [SWS_SecOC_91014].

Parameter

Als einziger Übergabeparameter dient der In-Parameter verificationStatus vom Typ SecOC_VerificationStatusType [SWS_SecOC_91014]. Diese Struktur liefert Details über den Verifikationsstatus sowie die Information, für welche Data-ID und Freshness-Value-ID die Verifikation durchgeführt wurde [SWS_SecOC_91014]. Zusätzliche Ein- oder Ausgabeparameter existieren nicht [SWS_SecOC_91014].

Fehlerbehandlung und Nebenläufigkeit

Spezifische Fehlercodes sowie Benachrichtigungen an DET oder DEM sind für diesen Service nicht definiert [SWS_SecOC_91014]. Interpretation: Fehlgeschlagene Verifikationen dürften der Applikation primär über die Statuswerte innerhalb der übergebenen Struktur verificationStatus mitgeteilt werden. Frage Q-177be3d746f99b24 (offen) Bezüglich der Nebenläufigkeit ist SecOC_VerifyStatus nicht reentrant für dieselbe Freshness-Value-ID, jedoch reentrant für unterschiedliche Freshness-Value-IDs [SWS_SecOC_91014].

Der Aufzählungstyp SecOC_StateType dient der formalen Repräsentation der internen Betriebszustände des Moduls SecOC und wird über die Header-Datei SecOC.h bereitgestellt [SWS_SecOC_00162]. Er erlaubt eine konsistente Zustandsführung über den gesamten Lebenszyklus der Software-Komponente hinweg.

Gemäß Spezifikation umfasst der Wertebereich dieses Aufzählungstyps genau zwei diskrete Zustände [SWS_SecOC_00162]:

• SECOC_UNINIT: Signalisiert eindeutig, dass das SecOC-Modul nicht initialisiert ist [SWS_SecOC_00162].
• SECOC_INIT: Kennzeichnet verbindlich, dass das SecOC-Modul initialisiert wurde [SWS_SecOC_00162].

In Bezug auf Zusammenspiel und Reihenfolgebedingungen repräsentiert SECOC_UNINIT vermutlich den Standardzustand unmittelbar nach dem Systemstart. Frage Q-4d02fe3a0979113f (offen) In dieser Phase dürften funktionale Aufrufe zur kryptografischen Absicherung oder Verifikation von Botschaften abgewiesen werden, da notwendige Datenstrukturen noch nicht bereitstehen. Erst nach erfolgreicher Modulinitialisierung wechselt der Status vermutlich zu SECOC_INIT. Aufrufende Module oder interne Überwachungsroutinen dürften SecOC_StateType heranziehen, um den aktuellen Betriebsstatus synchron zu prüfen und unzulässige Zugriffe vor der Initialisierung zuverlässig zu unterbinden.

Der Aufzählungstyp SecOC_VerificationResultType dient zur Signalisierung der Ergebnisse bei der Verifikation gesicherter I-PDUs im Modul SecOC und wird über den Header Rte_SecOC_Type.h bereitgestellt [SWS_SecOC_00149].

Die Enumeration spezifiziert dabei folgende Ergebniswerte zur Differenzierung des Verifikationsstatus [SWS_SecOC_00149]:

• SECOC_VERIFICATIONSUCCESS (0x00): Die Verifikation der Daten war erfolgreich [SWS_SecOC_00149].
• SECOC_VERIFICATIONFAILURE (0x01): Die Verifikation war nicht erfolgreich [SWS_SecOC_00149].
• SECOC_FRESHNESSFAILURE (0x02): Die Verifikation schlug aufgrund eines fehlerhaften Freshness-Werts fehl [SWS_SecOC_00149].
• SECOC_AUTHENTICATIONBUILDFAILURE (0x03): Die Verifikation war aufgrund fehlerhaft aufgebauter Authentifizierungscodes nicht erfolgreich [SWS_SecOC_00149].
• SECOC_NO_VERIFICATION (0x04): Die Verifikation wurde übersprungen und die Daten wurden unverändert an die übergeordnete Schicht weitergeleitet; dieser Zustand ist nur bei aktiver Statusüberschreibung SecOC_VerifyStatusOverride möglich [SWS_SecOC_00149].
• SECOC_VERIFICATIONFAILURE_OVERWRITTEN (0x05): Die Verifikation schlug fehl, jedoch wurde die I-PDU infolge des Überschreibungsstatus dennoch an die obere Schicht übergeben; dieser Zustand tritt ebenfalls ausschließlich bei Nutzung von SecOC_VerifyStatusOverride auf [SWS_SecOC_00149].

Anhand dieser Werte können übergeordnete Schichten präzise auswerten, ob eine Verifikation regulär glückte, an kryptografischen Codes oder Freshness-Werten scheiterte oder ob administrative Override-Zustände die Datenweitergabe gesteuert haben [SWS_SecOC_00149].

Verwendung der Verifikationsstatus-Struktur

Der Strukturtyp SecOC_VerificationStatusType bündelt gemäß [SWS_SecOC_00160] das Ergebnis eines Verifikationsversuchs für eine gesicherte I-PDU zusammen mit der zugehörigen Data-ID und dem verwendeten Freshness-Wert. Die Definition wird über die Header-Datei Rte_SecOC_Type.h bereitgestellt und umfasst folgende Elemente:

• freshnessValueID (uint16): Kennung des Freshness-Werts, der zu dem Verifikationsstatus geführt hat ([SWS_SecOC_00160]).
• verificationStatus (SecOC_VerificationResultType): Detailliertes Ergebnis des Verifikationsversuchs ([SWS_SecOC_00160]).
• secOCDataId (uint16): Data-ID der betroffenen PDU ([SWS_SecOC_00160]).

Das Element verificationStatus differenziert spezifische Erfolgs- und Fehlerzustände ([SWS_SecOC_00160]):

• SECOC_VERIFICATIONSUCCESS: Die kryptografische Prüfung war erfolgreich.
• SECOC_VERIFICATIONFAILURE: Die Verifikation schlug fehl.
• SECOC_FRESHNESSFAILURE: Die Verifikation schlug aufgrund eines ungültigen Freshness-Werts fehl.
• SECOC_AUTHENTICATIONBUILDFAILURE: Fehlgeschlagene Verifikation infolge fehlerhaft erstellter Authentifizierungscodes.
• SECOC_NO_VERIFICATION: Es wurde kein Verifikationsversuch für diese I-PDU ausgeführt; sie wurde unverändert an die obere Schicht durchgereicht.
• SECOC_VERIFICATIONFAILURE_OVERWRITTEN: Die Verifikation schlug fehl, die I-PDU wurde jedoch aufgrund eines aktiven Override-Status an die obere Schicht weitergeleitet.

Interpretation: Da der Typ die Verifikationsdetails bündelt, dürfte er vor allem in Rückmelde- und Benachrichtigungsschnittstellen eingesetzt werden, um übergeordnete Schichten über den Authentifizierungszustand empfangener Daten zu informieren. Frage Q-a1099bc88a2981e2 (offen)

Der Enumerationstyp SecOC_OverrideStatusType definiert die verschiedenen Modi zur Übersteuerung des Verifikationsstatus von I-PDUs im Modul SecOC und wird über den Header Rte_SecOC_Type.h bereitgestellt [SWS_SecOC_00991].

Die Werte des Aufzählungstyps steuern, ob und wie die Verifikation des Authenticators erfolgt und wie mit der eingehenden I-PDU verfahren wird [SWS_SecOC_00991]:

• SECOC_OVERRIDE_DROP_UNTIL_NOTICE (0x00): Die Verifikation entfällt ohne CSM-Aufruf, die I-PDU wird verworfen und das Verifikationsergebnis auf SECOC_NO_VERIFICATION gesetzt [SWS_SecOC_00991].
• SECOC_OVERRIDE_DROP_UNTIL_LIMIT (0x01): Wie zuvor wird die Verifikation ausgesetzt und die I-PDU verworfen, jedoch begrenzt, bis die konfigurierte Anzahl zu übersteuernder Nachrichten erreicht ist [SWS_SecOC_00991].
• SECOC_OVERRIDE_CANCEL (0x02): Bricht die aktive Übersteuerung des Verifikationsstatus ab und stellt das reguläre Verhalten wieder her [SWS_SecOC_00991].
• SECOC_OVERRIDE_PASS_UNTIL_NOTICE (0x40) und SECOC_OVERRIDE_PASS_UNTIL_LIMIT (0x42): Die Authenticator-Verifikation wird ausgeführt und die I-PDU unabhängig vom Ergebnis an die obere Schicht weitergeleitet; schlägt die Verifikation fehl, wird das Ergebnis auf SECOC_VERIFICATIONFAILURE_OVERWRITTEN gesetzt (entweder bis auf Weiteres oder zählerbegrenzt) [SWS_SecOC_00991].
• SECOC_OVERRIDE_SKIP_UNTIL_LIMIT (0x41) und SECOC_OVERRIDE_SKIP_UNTIL_NOTICE (0x43): Die Verifikation entfällt, das Ergebnis lautet SECOC_NO_VERIFICATION, und die I-PDU wird an die obere Schicht übergeben. Ist SecOCRxSecuredPduCollection konfiguriert, verarbeitet SecOC die SecOCRxAuthenticPdu direkt, ohne auf die SecOCRxCryptographicPdu zu warten [SWS_SecOC_00991].