Meine Frage ist, ob es möglich ist, ein Applet innerhalb des Codes des Applets selbst als Gegenmaßnahme für erkannte Manipulationen innerhalb des Codes zu sperren.
Die offensichtliche Wahl ist die Verwendung von GPSystem.lockCard(); und es funktioniert, aber ich frage mich, ob es möglich ist, das Applet nur zu sperren. Außerdem kann ich das Applet selbst von einer authentifizierten Sitzung der zugehörigen Sicherheitsdomäne sperren. Aber ist es möglich, aus dem Applet-Code selbst. Es scheint, angesichts der GPSystem.setCardContentState(); -Methode mit GPSystem.APPLICATION_LOCKED verwendet, also habe ich auch getestet, aber es funktioniert nicht.
Lesen Sie erneut die Beschreibung der GP-Kartenspezifikation 2.2 PDF:
Das OPEN soll jegliche Übergangsanforderung von dem Lebenszyklusstatus LOCKED zurückweisen;
In meinem Eclipse sagt der JavaDoc:
Das OPEN soll jede Übergangsanforderung zu dem Lebenszyklusstatus LOCKED
zurückweisen
Was ist hier los?
Es ist interessant zu sehen, wie sich dieser Mechanismus aus der GlobalPlatform Card-Spezifikation 2.1.1 bis 2.2.1 entwickelt hat (immer noch in 2.3):
In GP 2.1.1 darf nur der Kartenaussteller (Off-Card-Entity) oder OPEN (als Folge von "Exceptions") das Sperren einer Anwendung initiieren:
Der Kartenherausgeber verfügt über einen Mechanismus, um den fortgesetzten Ausführungsstatus einer Anwendung auf der Karte zu deaktivieren. Dieser Mechanismus kann innerhalb des OPEN basierend auf Ausnahmen, die von OPEN oder von extern aufgerufenen Befehlen gehandhabt werden, aufgerufen werden. Der Kartenherausgeber ist die einzige Entität, die das Sperren einer Anwendung auslösen kann.
Die Methode GPSystem.setCardContentState() ist eindeutig definiert, um nur Zustandsänderungen in anwendungsspezifischen Lebenszykluszuständen zuzulassen (Werte zwischen 0x07 und 0x7F mit den niedrigsten 3 gesetzten Bits). Da die Konstante für APPLICATION_LOCKED in späteren Spezifikationen 0x80 ist, ist das Setzen dieses Status nicht erlaubt. Dies wird auch in den Anmerkungen zu dieser Methode deutlich gemacht:
- Der OPEN muss jegliche Übergangsanforderung zu den Life Cycle States INSTALLED oder LOCKED zurückweisen.
Folglich muss der Versuch, den Anwendungsstatus innerhalb der Anwendung selbst zu sperren, auf einer Karte fehlschlagen, die GP 2.1.1 implementiert.
UPDATE (2016-05-20): Ich habe dies auf einigen NXP JCOP-Karten getestet (die angeblich GP 2.1.1 entsprechen) und setze Werte wenn das obere Bit gesetzt ist oder eines der unteren 3 Bits gelöscht ist, schlägt dies fehl.
Dies hat sich in GP 2.2 geändert. Jetzt darf sich eine Anwendung selbst sperren:
Die Karte verfügt über einen Mechanismus zum Deaktivieren und anschließenden erneuten Aktivieren des fortgesetzten Ausführungsstatus einer Karte Anwendung. Dieser Mechanismus kann aus dem OPEN heraus aufgerufen werden, basierend auf Ausnahmen, die von OPEN oder bearbeitet werden von der Verwendung von extern aufgerufenen Befehlen. Eine Anwendung mit Global Lock-Berechtigung, die Anwendung selbst oder Eine direkt oder indirekt zugeordnete Sicherheitsdomäne sind die einzigen Entitäten, die die Sperrung eines Anwendung.
Die GP-Kartenspezifikation erfordert keine Anwendung, die eine bestimmte Berechtigung zum Sperren selbst besitzt.
Leider ist die API-Spezifikation für die Methode GPSystem.setCardContentState() immer noch nicht ganz klar. Erstens, die Beschreibung der Methode besagt immer noch, dass nur Werte zwischen 0x07 und 0x7F mit den niedrigsten 3 gesetzten Bits erlaubt sein dürfen:
Diese Methode legt den anwendungsspezifischen Lebenszyklusstatus des aktuellen Applet-Kontexts fest. Anwendungsspezifische Life Cycle States reichen von 0x07 bis 0x7F, solange die 3 niedrigwertigen Bits gesetzt sind.
Zweitens gibt es abweichende Hinweise in der API-Dokumentation, die Teil von Anhang A des Dokuments der GP-Kartenspezifikation 2.2 und des JavaDoc in den API-Exportdateien ist. Während die Notizen in der Spezifikation geändert wurden:
- Die OPEN muss jede Übergangsanforderung in den Lebenszyklusstatus INSTALLED
ablehnen- Die OPEN-Methode weist jede <<> Übergangsanforderung des Lebenszyklusstatus LOCKED ;
zurück
Die Notizen in den API-Exportdateien (GPSystem.java und JavaDoc) blieben dieselben wie in GP 2.1.1.
Wenn diese Methode entsprechend der Spezifikation implementiert wurde, sollte der Anwendungslebenszyklus-Status weiterhin auf APPLICATION_LOCKED gesetzt werden.
UPDATE (2016-05-20): Ich habe dies auf einer NXP J3D081 (JCOP v2.4.2 R2) Karte getestet (die angeblich GP 2.2 entspricht) ). Das Setzen von Werten, bei denen das obere Bit gesetzt oder eines der unteren 3 Bits gelöscht wurde, schlägt leider fehl.
Allerdings gibt es auch die Methode GPRegistryEntry.setState() . Die Dokumentation dieser Methode besagt, dass:
- Eine Übergangsanforderung in einen anderen Lebenszyklusstatus als APPLICATION_LOCKED und APPLICATION_UNLOCKED wird nur akzeptiert, wenn die aufrufende Anwendung diesem GPRegistryEntry entspricht;
- Eine Anwendung muss sperren können und nicht in der Lage sein, sich selbst zu entsperren;
Es wäre also interessant zu sehen, ob das Folgende auf derselben Karte funktioniert, wo setCardContentState() fehlgeschlagen ist:
UPDATE (2016-05-20): Ich habe dies auf einer NXP J3D081 (JCOP v2.4.2 R2) Karte getestet (die angeblich GP 2.2 entspricht) ). Das scheitert leider auch. Übrigens. Es scheint keinen Unterschied zu machen, ob null oder JCSystem.getAID() als Parameter für getRegistryEntry() verwendet wird.
UPDATE (14.06.2016): Laut Paul Bastian , ein NXP-Vertreter, hat bestätigt, dass sich Anwendungen auf JCOP v2.4.x-Karten nicht im gesperrten Zustand befinden können.
UPDATE (2016-06-06): Ich habe das auf einer Infineon SLE97CNFX-Karte getestet (die angeblich GP 2.2.1 entspricht) und es hat funktioniert. Ich konnte den Status erfolgreich sperren, indem ich APPLICATION_LOCKED (0x80) verwendete. Der Status wird dann auf previous_state | 0x80 festgelegt. Der Versuch, andere Statuswerte zu setzen, bei denen das obere Bit gesetzt ist (z. B. 0x8F), funktioniert nicht (wie erwartet).
In GP 2.2.1 wurde die Dokumentation der Methode GPSystem.setCardContentState() (wieder) geändert. Der Änderungshinweis zeigt deutlich, dass die Methode aktualisiert wurde, um einer Anwendung zu ermöglichen, sich selbst zu sperren (Dateiversion 1.5 exportieren. Maps zu GP 2.2.1):
- export file version 1.5: Diese Methode erlaubt nun der Anwendung, die mit dem aktuellen Applet-Kontext verknüpft ist, sich selbst zu sperren.
Die Methodendefinition wurde geändert in:
Diese Methode ermöglicht der Anwendung, die dem aktuellen Applet-Kontext zugeordnet ist, den Status in einen anwendungsspezifischen Lebenszykluszustand zu ändern oder sich selbst zu sperren . Eine Anwendung kann sich mit dieser Methode nicht selbst entsperren.
Der Wertebereich für den an die Methode übergebenen Zustandsparameter enthält jetzt explizit den Wert von APPLICATION_LOCKED :
bState- ein anwendungsspezifischer Lebenszykluszustand (0x07 bis 0x7F mit 3 niederwertigen Bits) oderAPPLICATION_LOCKED(0x80).
Folglich sollten Karten, die GP 2.2.1 oder höher implementieren, es Anwendungen ermöglichen, ihren eigenen Lebenszyklusstatus mithilfe der Methode GPSystem.setCardContentState() zu sperren.
UPDATE (2016-06-06): Ich habe das auf einer Infineon SLE97CNFX-Karte getestet (die angeblich GP 2.2.1 entspricht oder 2.3 ?)) und es hat funktioniert. Ich konnte den Status erfolgreich sperren, indem ich APPLICATION_LOCKED (0x80) verwendete. Der Status wird dann auf previous_state | 0x80 festgelegt. Der Versuch, andere Statuswerte zu setzen, bei denen das obere Bit gesetzt ist (z. B. 0x8F), funktioniert nicht (wie erwartet).
Was Sie tun könnten, um Ihr Problem zu lösen, ohne den Anwendungslebenszyklus auf den Status APPLICATION_LOCKED einstellen zu können, ist die Verwendung anwendungsspezifischer Lebenszykluszustände:
Wenn Sie ein Problem feststellen, das dazu führen könnte, dass Ihre Anwendung gesperrt wird, können Sie das Applet mit dem folgenden Aufruf sperren:
%Vor%Sie können die Anwendung später wieder entsperren, indem Sie einen SET STATUS-Befehl über die Sicherheitsdomäne verwenden.
(Käufer Vorsicht: Es scheint so, dass es einfach nicht funktioniert - siehe Kommentare)
(Im Zusammenhang mit GlobalPlatform Card Specification 2.2.1)
Sie müssen die in Abbildung 5-2 dargestellten Anwendungslebenszyklus-Statusregeln einhalten (der mit '5' markierte Pfeil gilt hier).
Der richtige Weg sollte sein:
%Vor%oder
%Vor% Der Status 0x80 life cycle ist für eine Anwendung ungültig. Siehe Tabelle 11-4 (mindestens die Bits b1 und b2 müssen gesetzt sein, wahrscheinlich auch das b3 -Bit).
BEARBEITEN & gt;
(Ich gestehe, dass ich diese Antwort nur basierend auf der Erinnerung an Tatsache schreiben soll, dass OPEN den ursprünglichen Zustand behält, aus dem die Entität gesperrt wurde)
Ich bin ziemlich neugierig darauf, also habe ich ein paar Tests mit dem folgenden Applet (Auszug) gemacht:
%Vor%Und die folgenden APDUs:
%Vor%Die Ergebnisse für meinen Kartensatz (Gemalto, Morpho, JCOP - leider sind alle GP 2.1.1) stimmen mit Michael Rolands guter Antwort und GP-Spezifikationen überein - der Versuch der Anwendung, sich selbst zu blockieren, wird abgelehnt.
Antwort-APDUs für alle GP 2.1.1-Karten erhalten:
%Vor%Nur ein Hinweis: Dieses Tool ist sehr nützlich, um die implementierte GP-Version beim Parsen der Karte zu bestimmen Erkennungsdaten.
Es gibt keine Einhaltung der GP-Kernspezifikationen per se. Ein Produkt ist GP-konform mit einer GP -Konfiguration . GP Konfiguration ist nicht kostenlos. JCOP 2.4.x-Produkte entsprechen der GP 2.2.x-Mapping-Richtlinien der bestehenden GP 2.1.1-Implementierung auf v2.2.1-Konfiguration. Wie der Name schon sagt, dient diese Konfiguration der Abwärtskompatibilität. Grundsätzlich sind JCOP 2.4.x-Produkte nur GP 2.1.1-konforme Produkte (mit einigen Funktionen von GP 2.2.x). Die globale Sperre ist für Applets optional.
Ja. Es ist eine übliche und beabsichtigte Operation einer GlobalPlatform-Anwendung. Sie müssen Ihre Anwendung mit der richtigen Berechtigung installieren (gp -install -privs CardLock), und der Code dafür lautet:
%Vor%Sie können die Anwendung später mit
entsperren %Vor%Tags und Links security smartcard lifecycle javacard globalplatform