Projekt 268 – Spezifikation der API von nativen Smartcardbetriebssystemen
Bei PC-Betriebssystemen existiert eine klare Trennung zwischen dem eigentlichen Betriebssystem und darauf aufbauenden Anwendungen durch standardisierte Schnittstellen (etwa Win32/Win64). Dies erlaubt eine klare Trennung zwischen Applikationsentwickler und Betriebssystementwickler. Im Bereich von Software auf Sicherheitselementen – wie z.B. Smartcards – findet derzeit keine klare Separation zwischen Anwendungs- und Betriebssystemfunktionalität statt. Zwar existieren im Bereich JavaCard Ansätze für eine solche Trennung: Hier können Anwendungen in Form von Java-Bytecode auf die Karte geladen werden, die zur Ausführung vom Betriebssystem interpretiert werden. Aufgrund der Interpretation des Bytecodes ist die Ausführungsgeschwindigkeit jedoch gering. Daher werden zeitkritische, insbesondere Sicherheitsfunktionen, aus der Anwendung extrahiert und separat als Teil des Betriebssystems oder als proprietäre Erweiterung implementiert. Bei nativen Betriebssystemen – als Alternative zu JavaCard basierten Systemen – existiert keine nach außen hin sichtbare Schnittstelle zwischen Applikation und Betriebssystem. Der Projektgegenstand umfasst: – eine technische Spezifikation einer Application API und einer Low-Level Crypto API, so dass Applikationen und Cryptolib in nativer Geschwindigkeit auf der Smartcard ausgeführt werden können. – (z.T. als optionale Pakete) prototypisches Testen der Implementierung auf einer Smartcard durch den Auftragnehmer mittels Testanwendungen und Testkryptolib. – (z. T. als optionale Pakete) die Bereitstellung von Development-Tools und Smartcard-Samples an den Auftraggeber, so dass der Auftraggeber Testapplikationen bzw. eine Testkryptolib prinzipiell selbst installieren und evaluieren kann. Der Hauptaugenmerk der Studie ist die Spezifikation der Application API und der Low-Level Crypto API. Prototypische Tests und Tools sind dem nachgeordnet, und dienen lediglich zum Nachweis der Machbarkeit der in der Studie formulierten Ergebnisse. Ein Teil der Tests und Tools sind optional (siehe Leistungsbeschreibung).
Deadline
Die Frist für den Eingang der Angebote war 2016-07-05.
Die Ausschreibung wurde veröffentlicht am 2016-05-23.
Wer?
Wie?
Wo?
Geschichte der Beschaffung
Datum |
Dokument |
2016-05-23
|
Auftragsbekanntmachung
|
2016-06-20
|
Ergänzende Angaben
|
2016-10-10
|
Ergänzende Angaben
|