DE102017010430A1

DE102017010430A1 - Verfahren zum Bewahren von Flashspeicher durch sequenzielle Belegung durch Einmalcode-Module

Info

Publication number: DE102017010430A1
Application number: DE102017010430.1A
Authority: DE
Inventors: Vivek Joshi; Abhay Lanke
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: Giesecke and Devrient ePayments GmbH
Priority date: 2017-11-10
Filing date: 2017-11-10
Publication date: 2019-05-16
Anticipated expiration: 2037-11-11
Also published as: DE102017010430B4

Abstract

Offenbart werden hierin Aspekte, die auf die effektive Personalisierung von Smartcards gerichtet sind, wobei die Flashspeicher-Nutzung optimiert wird, einschließlich insbesondere der Regenerierung von Flashspeicherbereich, der durch redundanten Code belegt ist, insbesondere durch sequenzielles Überschreiben von Einzelverwendungscode-Modulen, die an der Personalisierung dieser Smartcards beteiligt sind. Des Weiteren sind die Offenbarungen hierin ferner auf einen kundenspezifischen Bootloader und ein Kartenpersonalisierungswerkzeug zum Ermöglichen des vorgeschlagenen Verfahrens gerichtet.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein Protokolle zum Zugreifen, Adressieren und Zuweisen von nichtflüchtigen Speicherblöcken, und insbesondere Verbesserungen darin, die auf die Erhöhung der Verfügbarkeit von Freiraum und der Lebensdauer in den nichtflüchtigen Speicherblöcken gerichtet sind.
Insbesondere ist die vorliegende Erfindung ein Verfahren, das darauf gerichtet ist, die oben erwähnten Absichten für einen in eingebetteten Systemen, insbesondere Smartcards, enthaltenen Flashspeicher zu erreichen, indem die Belegung durch Einmalcode-Module darin sequenziell erfolgt.
Hintergrund der Erfindung
CN 102 760 075 A offenbart ein Verfahren in einer Smartcard, welches sicherstellt, dass die Daten sicher und verlässlich abgespeichert werden.
Nichtflüchtige Speichersysteme, insbesondere Flashspeichersysteme, haben aufgrund ihres niedrigen Stromverbrauchs, ihrer kleinen Größe, ihren niedrigen Kosten, geringen Wärmeerzeugung und hohen Stabilität immens an Beliebtheit gewonnen. Heutzutage werden auf Flashspeichern basierende Systeme meistens entweder in einem entfernbaren Formfaktor, einschließlich Speicherkarten oder Flashlaufwerke, die in Host-System/en wie etwa Personalcomputer, Kameras, und so weiter betreibbar aufgenommen werden können, oder alternativ in einem eingebetteten Formfaktor innerhalb von Systemen integriert, die Smartcards, SIMs enthalten, die ihre eigenen Verarbeitungsumgebungen aufweisen, aber als solche in größeren Host-Systemen, einschließlich Geldautomaten, Smartphones, Anwesenheitsendgeräte etc. aufgenommen werden, bereitgestellt.
Wenn Daten in den nichtflüchtigen Speicher geschrieben werden, ordnet der Host unabhängig vom Einsatzformfaktor Sektoren, Clustern oder anderen Dateneinheiten innerhalb eines kontinuierlichen virtuellen Adressraums des Speichersystems typischerweise eindeutige logische Adressen zu. Eine allgemein innerhalb des Speichersystems befindliche Steuerung übersetzt von dem Host empfangene logische Adressen in physische Adressen innerhalb der Speicheranordnung, in der die Daten tatsächlich gespeichert werden, und verfolgt dann diese Adressübersetzungen für eine spätere Abfrage. Vordefinierte Zyklusdauer und einseitig gerichtete Schreibverlaufscharakteristik bei Flashspeichersystemen werden als einschränkend für wiederholte Iterationen des zuvor beschriebenen Schreibprozesses betrachtet. Deshalb braucht das Fachgebiet einen Weg, der einfach und kostengünstig ist, aber bei der Verlängerung der Lebensspanne von eingebauten Flashspeichern und deshalb der Nutzungsdauer von Systemen, welche die Flashspeicher integrieren, hilft.
Der Lebenszyklus von Systemen, die diese Flashspeicher integrieren, wird durch die programmierte(n) Anwendung(en) und deren Betriebsfrequenz, welche seitens des für das System verantwortlichen Benutzers verursacht wird, definiert. Im unmittelbaren Geltungsbereich der vorliegenden Erfindung wird der Lebenszyklus von Smartcards als viele Zustände umfassend betrachtet, einschließlich: a) Registrierung bei einem Smartcard-Verwaltungssystem, b) Personalisierung zur Ausgabe an eine Person, c) Inbetriebsetzen zur Verwendung, d) Ausführung des auf der Smartcard programmierten Betriebs, e) Hinzufügen von nachfolgenden Anwendungen, die auf der Smartcard ausgeführt werden sollen, f) Blockieren oder Löschen der Smartcard aus dem Verwaltungssystem und g) Wiederherstellung zur Verwendung, um nur einige zu nennen.
Die meisten Übergänge zwischen den oben erwähnten Zuständen im Lebenszyklus von Smartcards enthalten unveränderlich eine oder mehrere Schreiboperationen im eingebauten nichtflüchtigen Speicher, welche die Schreib-Zählung und damit die Annäherung an die Gebrauchsdauer der Speichereinheit voranschreiten lassen. Begrenzungen von Speicherraumbeschränkungen und verfügbarer Flashspeicherdichte sind Haupthindernisse bei der Erweiterung der Kapazität der Flashspeichersysteme. Es wäre deshalb wünschenswert, die Residenz von Daten auf Flashspeicherblöcken zu minimieren, um deshalb einen großen Teil davon zum Empfangen von weiteren Daten über nachfolgende Auslösch-/Schreiboperationen freizugeben und in der Folge auch die ungleichmäßige Abnutzung der Speicherblöcke durch Reduzieren der Abhängigkeit von spezifischen Speicheradressen für wiederholte Auslösch-Schreib-Zyklen zu reduzieren.
Unter den oben erwähnten Lebenszykluszuständen bezieht sich die Personalisierung auf das elektronische On-Chip-Laden von Anwendungscodes, Benutzerdaten und kryptographischen Schlüsseln und ist ein anfänglicher Herstellungsprozess, wodurch allgemeine serienmäßig hergestellte Smartcards in individuell eingerichtete Karten umgewandelt werden, die in einer oder mehreren programmierten Anwendungen verwendet werden können.
Heutzutage verwendete Personalisierungsprotokolle erfordern das Laden von vielen funktionellen Modulen oder Applets in vorbezeichnete Bereiche innerhalb des Flashspeichers der allgemeinen serienmäßig hergestellten Karten. Es gibt gewisse Module, die einen einzigen Verwendungsfall haben und nach dem Zeitpunkt der Personalisierung der Zielkarte überflüssig werden. Das Laden von solchen Daten an bestimmten dafür vorgesehenen Adressen blockiert den Flashspeicher im gleichem Maß und erhöht deshalb die Belegung der Flashspeichereinheit. Es wäre deshalb wünschenswert, dass eine solche Datenresidenz optimiert wird, damit eine großer Teil von Flashspeicherbereichen frei bleiben kann, zusätzlich dazu, dass diejenigen die verwendet wurden, wiederhergestellt werden, um dadurch die Verfügbarkeit von eingebauten Flashspeichern und zusätzlich die Nutzungsdauer von Systemen, die solche Flashspeicher integrieren, zu verbessern.
Im Stand der Technik werden einige wenige Versuche zur Lösung der oben erwähnten Betrachtungen erwähnt. Zum Beispiel offenbart US7272086 (erteilt für Samsung Electronics Co Ltd) ein Verfahren zum logischen Überschreiben von Daten in einem einmal beschreibbaren Informationsspeichermedium, das zum physischen Überschreiben nicht in der Lage ist, so dass Daten einfach aktualisiert und/oder ausgelesen werden, und eine Datenaufzeichnungs- und/oder eine Wiedergabevorrichtung dafür. Hier wird ein Befehl zum Überschreiben neuer Daten in einem ersten Bereich des einmal beschreibbaren Informationsspeichermedium, worin Daten bereits aufgezeichnet wurden, ausgegeben. Dann wird der erste Bereich als fehlerhafter Bereich angesehen, und die neuen Daten werden in einem zweiten Bereich aufgezeichnet. Danach werden aktualisierte Fehlerverwaltungsinformationen, einschließlich Informationen über den Ort des ersten und zweiten Bereichs, im einmal beschreibbaren Informationsspeichermedium aufgezeichnet. Dieses Verfahren beruht jedoch auf dem Bestimmen fehlerhafter Bereiche und einem zusätzlichen Fehlerverwaltungssystem, das somit das Überschreiben dieser Speicherbereiche fortführt.
Ein anderes Beispiel, die US20140229025 (der Rain Bird Corp. zugeteilt), offenbart einen Codeersatz für Bewässerungssteuerungen, wobei ein Bootloader bereitgestellt wird, der die Kopie des zweiten Codesatzes, der über eine entfernbar eingesteckte Steckeinrichtung empfangen wird, über einen ersten Codesatz schreibt, mit Ausnahme des Bootloaders, der nicht überschrieben wird. Dieses System ist jedoch nicht in der Lage, Anforderungen der Flashspeicherverwaltung, insbesondere Ermüdung durch Abnutzung und Redundanz von Dateien, jenseits des Verwendungsfalls, der in dem angeführten Dokument dargelegt ist, zu erfüllen, welches ansonsten laut der vorgeschlagenen Lösung einen Vorteil hat beim Erzielen von Aufrüstungen oder zusätzlichen Funktionalitäten für einen vorhandenen Codesatz, der an einem Speicherort vorliegt.
Der Stand der Technik zeigt in dem oben dargestellten Ausmaß keine einzige wirksame Lösung auf, die alle zuvor erwähnten Betrachtungen angeht, wodurch eine akute Erfindungsnotwendigkeit für die vorliegenden Erfinder gewahrt wurde, die als Ergebnis ihrer gezielten Forschung mit neuartigen Lösungen zum endgültigen Erfüllen der Anforderungen des Fachgebiets aufwarten. Die nachfolgenden Offenbarungen ermöglichen ein besseres Verstehen der Gegenstände, Vorteile, Merkmale, Eigenschaften und Beziehungen der vorliegenden Erfindung.
Aufgaben der vorliegenden Erfindung
Die vorliegende Erfindung wird dadurch identifiziert, dass sie mindestens alle größeren Mängel, die im vorstehenden Abschnitt besprochen wurden, angeht, durch effektives Angehen der unten angegeben Aufgaben. Darin
ist es eine primäre Aufgabe, ein Verfahren zum Optimieren der Nutzbarkeit eines Flashspeichers, oder zur anderweitigen Vermeidung von dessen Verschwendung, in eingebetteten Systemen, insbesondere Smartcards bereitzustellen.
ist es eine weitere Aufgabe, neben der/den oben erwähnten Aufgabe(n), dass das so bereitgestellte Verfahren insbesondere das Problem von redundanten Daten angeht, die sich in eingebetteten Systemen innerhalb des Flashspeichers befinden.
ist es eine weitere Aufgabe, neben der/den oben erwähnten Aufgabe(n), dass das so bereitgestellte Verfahren implementiert werden kann ohne dass Modifikationen, oder wenn überhaupt nur minimale Modifikationen, an vorhandenen eingebetteten Systemen, insbesondere Smartcards, erforderlich sind.
ist es eine weitere Aufgabe, neben der/den oben erwähnten Aufgabe(n), dass das so bereitgestellte Verfahren kostengünstig zu implementieren ist und keine speziellen Fachkenntnisse oder Kenntnisse von Seiten des Benutzers erfordert, der für das eingebettete System, insbesondere für eine mit dem Verfahren ausgestattete Smartcard verantwortlich ist.
ist es eine weitere Aufgabe, neben der/den oben erwähnten Aufgabe(n), dass das so bereitgestellte Verfahren dazu verwendet werden kann, ein Initialisierungswerkzeug für die effektive Personalisierung von eingebetteten Systemen, insbesondere Smartcards einzuführen, wahrend die Flashspeicher-Nutzung optimiert wird.
Diese und andere Aufgaben und ihre Erreichung werden für den Leser mit den folgenden ausführlichen Offenbarungen und den angefügten unabhängigen Ansprüchen 1 und 11 ersichtlich. Andere Komponenten, Merkmale und die Art und Weise ihrer Implementierung sind in den abhängigen Ansprüchen umrissen.
Kurzfassung der vorliegenden Erfindung
Gemäß der vorliegenden Erfindung wie derzeit vorgesehen wird hiermit ein Verfahren zum Bewahren von Flashspeicher durch sequenzielle Belegung durch Einzelverwendungscode-Module bereitgestellt. Beim Implementieren des Verfahrens während des Herstellungsprozesses für Smartcards werden Einzelverwendungscode-Module, die als sich gegenseitig ausschließend identifiziert sind, gemäß der Logik für ihre Ausführung zur Personalisierung sequenziell geladen, wodurch eine Flashspeicherplatzverschwendung, die sich ansonsten aus dem Laden von jedem der Einzelverwendungscode-Module in separaten Bereichen innerhalb des Flashspeichers ergibt, vermieden wird. Dieses Verfahren führt einen individuell eingerichteten Bootloader und ein darauf basierendes Kartenpersonalisierungswerkzeug zur effektiven Personalisierung von Smartcards, während die Flashspeicher-Nutzung optimiert wird, ein.
Figurenliste
Die obengenannten und weitere Aspekte, Merkmale und Vorteile von mehreren Ausführungsformen der vorliegenden Erfindung werden aus dem nachfolgend bereitgestellten Abschnitt der detaillierten Beschreibung besser ersichtlich, der in Verbindung mit den folgenden Zeichnungen dargestellt wird. Darin zeigen:

1 ein Blockdiagramm zur schematischen Veranschaulichung der Methodik zum Regenerieren von Flashspeicher, der durch Einmal-Codes belegt ist, im Wesentlichen gemäß der hierin dargelegten Offenbarungen.

In der/den obengenannten Zeichnung/en wurden, wo immer möglich, durchgehend dieselben Ziffern zur Bezeichnung derselben oder ähnlichen Komponenten oder Indexe wie folgt verwendet:

001 -: Proprietärer Bootloader
002 -: Schritt zum Herunterladen des Betriebssystems (OS, engl. Operating System)
003 -: Modul für die Funktionalität CreDe
004 -: Betriebssystem
005 -: Freiraum innerhalb des Flashspeichers der Smartcard
006 -: Schritt zum Herunterladen üblicher Personalisierungsdateien unter Verwendung von CreDe
007 -: Dateisystem, das dedizierte Dateien und/oder Elementardateien umfasst
008 -: Schritt zum Ermöglichen des Herunterladens eines Mastereinrichtungspatch
009 -: Befehl zum Herunterladen eines Mastereinrichtungspatch
010 -: Modul für Mastereinrichtungspatchfunktionalität
011 -: Schritt zur Herstellung von mehreren Karten

Eine Bezugnahme auf bestimmte Beispiele und Implementierungen geschieht nur zu veranschaulichenden Zwecken und soll den Schutzbereich der Erfindung oder der Ansprüche nicht beschränken. Obgleich eine Nummerierung in der detaillierten Beschreibung und in den Ansprüchen eingeführt wurde, um einen Bezug auf spezifische Komponenten bezüglich solcher Referenzen, die in anderen Abschnitten dieser Spezifikation gemacht werden, abzugrenzen, werden nicht alle Komponenten in jeder Zeichnung gezeigt oder mit einer Nummer versehen, um eine Verschleierung der vorgeschlagenen Erfindung zu vermeiden.
Die Aufmerksamkeit des Lesers soll nun auf die folgende detaillierte Beschreibung gelenkt werden, die eine bevorzugte Ausführungsform der vorliegenden Erfindung und andere Art und Weisen, in denen die Prinzipien der Erfindung genutzt werden können, beschreibt, ohne vom Wesen der hierin beanspruchten Erfindung abzuweichen.
Detaillierte Beschreibung
Im Prinzip ist der allgemeine Zweck der vorliegenden Erfindung, Unfähigkeiten und Mängel, die bekannten Systemen innewohnen, die den Stand der Technik umfassen, zu bewerten und neue Systeme zu entwickeln, die alle verfügbaren Vorteile der bekannten Technik und keine ihrer Nachteile einbinden.
Vor der nachfolgenden detaillierten Beschreibung der Erfindung kann es vorteilhaft sein, Definitionen von überall in dieser Patentschrift verwendeten gewissen Wörtern oder Ausdrücken darzulegen: Die Begriffe „enthalten“ und „umfassen“ sowie deren Ableitungen bedeuten einschließen, ohne darauf beschränkt zu sein; der Begriff „oder“ ist einschließend und bedeutet und/oder; die Ausdrücke „zugeordnet“ und „irgendetwas zugeordnet“, sowie deren Ableitungen können enthalten, innerhalb von etwas enthalten, miteinander verbunden, mit, beinhalten, in etwas beinhaltet sein, zu oder mit etwas verbinden, zu oder mit etwas koppeln, kommunizieren können mit, kooperieren mit, verzahnen, nebeneinander stellen, in der Nähe sein von, gebunden sein an oder mit, aufweisen, eine Eigenschaft aufweisen oder dergleichen bedeuten; und der Begriff „OS“ bezieht sich auf Betriebssystem oder allgemein auf irgendein auf die Smartcard herunterzulandendes Softwareprogramm; „ASIC“ bezieht sich auf eine anwendungsspezifische Schaltung; „FPGA“ bezieht sich auf eine feldprogrammierbare Gatteranordnung; „CrDe“ bezieht sich auf Create- und Delete(zu Deutsch: Erstelle und Lösche)-Funktionalitäten; „MD“ bezieht sich auf eine Mastereinrichtung; „CRC“ bezieht sich auf eine zyklische Redundanzprüfung; „APDU“ bezieht sich auf eine Anwendungsprotokolldateneinheit.
Entsprechend wird ein Ansatz zum Reduzieren der Gesamtbelegung von Speicherblöcken innerhalb der Flashspeichereinheit, um diese frei und verfügbar für eine weitere Verwendung während des Lebenszyklus der betreffenden Smartcard zu machen, vorgeschlagen, dessen Ermöglichung anhand gewisser nicht einschränkender Ausführungsformen besprochen wird, von denen einige unten anhand gewisser Beispiele erklärt werden, die allgemein die Art und Weise veranschaulichen, wie Prinzipien der vorliegenden Erfindung genutzt werden können.
Wie im vorstehenden Teil dieses Dokuments erwähnt, erfordern heutzutage verwendete Protokolle für die Personalisierung von Smartcards das Laden von vielen funktionellen Einzelverwendungscode-Modulen oder Applets auf vorbezeichnete bestimmte Bereiche innerhalb des Flashspeichers der allgemeinen serienmäßig hergestellten Karten. Die vorliegenden Erfinder betrachten dieses Merkmal als eine angehbare Nische, da diese Einzelverwendungscode-Module nur einmal erforderlich sind und nach der Personalisierung redundant sind. Deshalb stellt ihr belegter Flashspeicher eine regenerierbare Ressource und die Art und Weise, wie derselbe für den Herstellungsprozessablauf regeneriert wird, bildet das Wesen der hierin beanspruchten Erfindung.
Zu Beginn schlagen die vorliegenden Erfinder einen Ansatz vor, um Einzelverwendungscode-Module, insbesondere CrDe -und MD-Funktionalitäten, die sich bekanntermaßen gegenseitig ausschließen, gemäß der logischen Sequenz ihrer programmierten Ausführung während des Personalisierungsprozesses sequenziell zu überschreiben. Insofern wird CrDe verwendet, um die Dateien auf dem Dateisystem zu erstellen und zu löschen, und die MD-Funktionalität wird zum Lesen der Flashinhalte oder des Abbilds des Flash als Herstellungsdateiformat, zum Beispiel eine .mot-Datei, verwendet. Sowohl CrDe als auch MD sind nur zum Zeitpunkt der Herstellung und nicht später während des Nutzungsdauer der Smartcard erforderlich.
Basierend auf dem im vorhergehenden Absatz erwähnten Ansatz und wie insbesondere in 1 veranschaulicht, ist es in dem hierin beanspruchten erfindungsgemäßen Herstellungsprozess vorgesehen, mit der Auswahl einer allgemeinen serienmäßig hergestellten Smartcard (nicht gezeigt) anzufangen.Die Smartcard wird durch einen proprietären Bootloader (001), der in einem Abschnitt ihres Flashspeichers vorinstalliert ist, individuell eingerichtet. Der proprietäre Bootloader (001) ist dazu programmiert, über Schritt (002) das CrDe-Modul (003) und OS (004) auf den Flashspeicher der Smartcard zu laden, wobei Raum (005) frei gelassen wird.
Unter fortlaufendem Bezug auf die begleitende 1 ist zu sehen, dass als Ergebnis der Ausführung von CrDe (003) ein Dateisystem (007), das dedizierte Dateien und/oder Elementardateien umfasst, über Schritt (006) (005) zur Personalisierung der Smartcard in den Freiraum geladen wird. Danach werden in Schritt (008) Lösche- und Initialisiere-Befehle des OS (004) ausgeführt, um in Schritt (009) das Laden des MD-Moduls (010) auf denselben Speicherort wie das CrDe-Modul (003) zu ermöglichen, wodurch eine Ausgangseinzelkarte, oder Masterkarte, gebildet wird, wodurch der Flashspeicher, der ursprünglich durch CrDe (003) belegt wurde, regeneriert wird.
Ferner ist mit fortlaufendem Bezug auf die begleitende 1 zu sehen, dass die Ausführung des MD-Moduls (010) das Lesen der Flashinhalte oder des Abbilds des Flash als Herstellungsdatei zur Folge hat, die auch Einzelheiten enthält, einschließlich Adresse, Byte-Anzahl und die CRC-Werte, unter dessen Verwendung als Vorlage nach Bedarf mehrere Karten hergestellt werden können. Es versteht sich aus dem Verlauf dieser Schritte, dass der Masterkarte die Funktionalität des CrDe-Moduls (003) deaktiviert wird, sobald das Herunterlademerkmal aktiviert ist.
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist der proprietäre Bootloader (001) eine computerimplementierte Routine, die dazu programmiert ist, einen Satz von Befehlen aufzuweisen, der darauf gerichtet ist, bei Ausführung die folgenden Funktionen zu erreichen:

a) Auslöschen einzelner oder mehrerer Sektoren des Flashspeichers auf der Smartcard. Das Befehlsformat dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, aus der der Flash ausgelöscht werden sollte; wohingegen die zwei wertniedrigsten Bytes die Anzahl von Seiten angeben, die ausgelöscht werden muss; die Werte von N und X können je nach Verwendungsfall bestimmt werden.
b) Initialisieren/Schreiben spezifischer Inhalte auf den Flashspeicher. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, ab der der Flash beschrieben werden muss, während der Rest der wertniedrigeren Bytes die auf den Flash zu schreibenden eigentlichen Datenbytes darstellen;
c) Verifizieren des Inhalts des beschriebenen Flash durch Validieren eines zuvor gelieferten CRC gegenüber eines intern durch die Karte berechneten. Das APDU-Befehlsformat für diesen Befehl weist N zusätzliche Datenbytes auf, unter denen die höchstwertigen X-Bytes der Daten die Adresse angeben, von denen aus die CRC-Berechnung erfolgen sollte. Die nächsten vier hochwertigen Bytes stellen dann die Anzahl von Bytes dar, auf denen die CRC-Berechnung erfolgen sollte. Die restlichen (N-X) Bytes der Daten stellen den erwarteten Wert der CRC dar, der durch das externe Werkzeug berechnet wird. Derselbe Wert wird mit dem berechneten Wert der CRC verglichen. Auf Basis dieses Vergleichs wird die positive oder negative Antwort des Verifikationsbefehls gegeben; und
d) Übergabe der Ausführungssteuerung vom Bootloader an das OS. Aufgrund dieses Befehls wird die erste Seite des Flash aktualisiert.

Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist das OS (004) eine computerimplementierte Routine, die dazu programmiert ist, unter anderem einen Satz von herstellungsspezifischen Befehlen aufzuweisen, der darauf gerichtet ist, bei Ausführung Folgendes zu erreichen, darunter:

a) Erstellen von für die Personalisierung der Smartcards notwendigen Dateien;
b) Löschung von für die Personalisierung der Smartcards notwendigen Dateien;
c) Auslöschen einzelner oder mehrerer Sektoren des Flashspeichers auf der Smartcard. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, aus der der Flash gelöscht werden sollte; wohingegen die wertniedrigsten verbliebenen (N-X)-Bytes die Anzahl von Seiten angeben, die ausgelöscht werden müssen;
d) Initialisieren/Schreiben spezifischer Inhalte auf den Flashspeicher. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, ab der der Flash beschrieben werden muss, während der Rest der wertniedrigeren Bytes die auf den Flash zu schreibenden eigentlichen Datenbytes darstellen;
e) Verifizieren des Inhalts des beschriebenen Flash durch Validieren eines gelieferten CRC gegenüber einem intern durch die Karte berechneten. Das APDU-Befehlsformat für diesen Befehl weist N zusätzliche Datenbytes auf, unter denen die höchstwertigen X-Bytes der Daten die Adresse angeben, von denen aus die CRC-Berechnung erfolgen sollte. Die restlichen Bytes der Daten stellen den erwarteten Wert der CRC dar, der durch das externe Werkzeug berechnet wird. Derselbe Wert wird mit dem berechneten Wert der CRC verglichen. Basierend auf diesem Vergleich wird die positive oder negative Antwort des Verifikationsbefehls gegeben;
f) Schutz der Herunterladefunktionalität des OS. Eine erfolgreiche Authentifizierung unter Verwendung dieses Befehls ist auf die Ermöglichung der Befehle bei Punkt c) bis e) in diesem Absatz gerichtet; und
g) Auslesen der Flashinhalte von der Karte. Dies ist ein optionaler Befehl, der der MD-Funktionalität als steckbares Modul dient.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung sind der proprietäre Bootloader (001) und das CrDe-Modul (003) unter einer Telefonbuch-Datei (wie etwa ein .ADN-Format) gruppiert, um dadurch Flexibilität bei der Dateigrößenzuweisung, beim Schutz gegen unbeabsichtigtes Löschen des proprietären Bootloader (001) und/oder des CrDe-Moduls (003) nach der Personalisierung und auch eine Wahl, den CrDe-Modul(003)-Raum im Hinblick auf die Telefonbuch-Datei zu regenerieren, da die Definition letzterer zum Zeitpunkt der Herstellung leer gelassen werden kann, zu erlauben. Die Telefonbuch-Datei wird zwingend aktualisiert, um den im vorhergehenden Absatz erwähnten Smartcardpersonalisierungsprozess abzuschließen. Das gilt auch für die mehreren Karten, die unter Verwendung der Herstellungsdatei vorbereitet werden, sowie für die Einzelkarte, die zum Erzeugen der Bildvorlage, die für die Herstellung von mehreren Karten zu verwenden ist, verwendet wird.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung geht dem Schritt (002) eine Auswahl einer Smartcard mit vorinstalliertem proprietären Bootloader (001), der sehr wenige Flashspeicher auf der Karte verbraucht, voraus. Die Ausführung des proprietären Bootloader (001) in Schritt (002) hat das Laden des CrDe-Moduls (003) und OS (004) auf den Flashspeicher der Smartcard gleich nach dem proprietären Bootloader (001) zur Folge.Danach wird die Karte zurückgesetzt, um das OS (004) zu aktivieren.
Durch Schritt (002) wird das CrDe-Modul (003) dem OS (004) zur Verfügung gestellt. In diesem Prozess kann der Flashbereich, der durch das CrDe-Modul (003) belegt ist, im Hinblick auf die Telefonbuch-Datei regeneriert werden, wodurch den alternativen Ausführungsformen, worin die Definition des zu regenerierenden Flashbereichs größer, gleich oder kleiner ist als die Kombination aus proprietärem Bootloader (001) und CrDe-Modul (003), Rechnung getragen wird.Sobald die Personalisierung auf diese Weise erfolgt ist, kann dann dieselbe Karte als endgültige Herstellungskarte verwendet werden, oder sie kann dazu verwendet werden, eine Vorlageherstellungsdatei für die Herstellung von mehreren Karten nach Bedarf zu erzeugen. Es sollte sich verstehen, dass die Telefonbuch-Datei jederzeit während der Personalisierung erstellt werden kann, wenn ihre Dateigröße kleiner oder gleich dem proprietären Bootloader (001) plus das CrDe-Modul (003) ist, ansonsten wird die Entfernung der Telefonbuch-Datei nicht in der Löschung des CrDe-Moduls (003) resultieren.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird der Schritt (008) als Befehl durch das OS (004) durchgeführt, um das Herunterladen des MD-Moduls (010) auf den Flashspeicherbereich, der von dem durch das CrDe-Modul (003) belegten Bereich regeneriert wurde, zu ermöglichen, um somit die Erzeugung der Vorlageherstellungsdatei zu erlauben. Diese Funktion wird dadurch geschützt, dass eine bestimmte Anzahl von Bytes (etwa A, 8 Bytes im Besonderen) des Authentifizierungswerts erforderlich sind, wenn dies nicht der Fall ist, sind der proprietäre Bootloader (001) plus das CrDe-Modul (003) eingerichtet, um von der Karte gelöscht zu werden, wodurch diese Funktion dauerhaft nicht mehr erlaubt ist. Ferner ist anzumerken, dass der Schritt (008) für eine einzige Ausführung eingerichtet ist und nicht wieder ausgeführt werden kann, falls die Karte während des Schritts (009) zurückgesetzt wird, wodurch das Herunterladen des MD-Moduls (010) dauerhaft deaktiviert ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird der Schritt (009) in Form von Lösche-Sektor- und Initialisiere-Befehlen durch das OS (004) durchgeführt, um das MD-Modul (010) auf den Flashspeicherbereich, der von dem durch das CrDe-Modul (003) belegten Bereich regeneriert wurde, herunterzuladen, wodurch das MD-Modul (010) als steckbares Teil des OS (004) selbst zur Verfügung gestellt wird. Und sobald das MD-Modul (010) heruntergeladen ist, kann die personifizierte Karte zum Einlesen der Flashinhalte in eine Herstellungsdatei verwendet werden, die wiederum zum Herstellen mehrerer Karten gemäß den Erfordernissen des Benutzers zu verwenden ist.
Aus dem Vorstehenden sollte es sich verstehen, dass es effektiv zwei zu regenerierende Flashbereiche gibt, die durch Belegungen des CrDe-Moduls (003) und des MD-Moduls (010) identifiziert sind. In alternativen Ausführungsformen kann es vorgesehen sein, dass das CrDe-Modul (003) und das OS (004) dazu eingerichtet sein können, um entweder diskrete oder zusammenhängende Orten innerhalb der Flashspeichereinheit der Smartcard zu belegen.
Wie leicht zu verstehen ist, wird das hierin vorgeschlagene Verfahren durch ein Konsortium von Werkzeugen / computerimplementierten Routinen ermöglicht, die dazu programmiert sind, die Schritte (002), (006), (009) und (011) durchzuführen. Herkömmliche Downloader, Personalisierungswerkzeuge und Lese-Flash-Werkzeuge können für die genannten Zwecke genutzt werden.
Obgleich 1 eine Anzahl von Operationen in einer bestimmten Reihenfolge veranschaulicht, können Operationen, die nicht reihenfolgeabhängig sind, neu geordnet werden und andere Operationen können kombiniert oder herausgenommen werden. Während einige Neuordnungen oder andere Gruppierungen eigens erwähnt werden, werden andere für den Fachmann ersichtlich sein und stellen somit keine erschöpfende Liste von Alternativen dar. Außerdem sollte es erkannt werden, dass die Phasen in Hardware, Firmware, Software oder irgendeiner Kombination daraus implementiert werden können.
Die vorliegende Erfindung wurde in einem beispielhaften Aufbau unter Verwendung eines Hardwaremoduls praktisch verwirklicht, und darin wurde identifiziert, dass sie die folgenden Vorteile gegenüber dem Stand der Technik aufweist:

a) Regenerierung von Flashspeicher, der entweder von CrDe- oder MD-Einmalcode-Modulen oder von beiden oder von keinem davon belegt ist;
b) Kontrolle über unbeabsichtigte Löschung des Bootloaders; und
c) Darstellung von Protokollen für die Herstellung von einzelnen und mehreren Karten, wodurch eine größere Flexibilität beim Herstellungsverfahrens erlaubt wird.

Bei der Interpretation dieses Dokuments können, um die Beschreibung zu vereinfachen, verschiedene Funktionen und Operationen oder ausführbare Routinen für dieselben als durch Softwarecode durchgeführt oder veranlasst beschrieben werden. Der Fachmann wird jedoch erkennen, dass mit solchen Ausdrücken gemeint ist, dass Funktionen aus der Ausführung des Codes/der Instruktionen oder der Routinen durch einen Prozessor, wie etwa ein Mikroprozessor, resultieren. Es sollte sich verstehen, dass die Funktionen und Operationen oder ausführbare Routinen zur Implementierung dieser Ausführungsformen als Teil eines Betriebssystems oder einer spezifischen Anwendung, Komponente, eines Programms, Objekts, Moduls oder einer Instruktionssequenz implementiert werden können.
Des Weiteren können die hierin angeführten Ausführungsformen oder weitere Varianten davon unter Verwendung festverdrahteter Beschaltung, wie etwa ASIC oder FPGA ohne Software-Befehle, oder in Kombination mit Software-Befehlen implementiert werden. Somit sind die hierin offenbarten Techniken weder auf irgendeine spezifische Kombination von Hardwarebeschaltung und Software, noch auf irgendeine bestimmte Quelle für die durch das Datenverarbeitungssystem ausgeführten Instruktionen beschränkt.
Wahrend einige hierin offenbarten Ausführungsformen in voll funktionsfähigen Computern und Computersystemen implementiert werden können, können verschiedene Ausführungsformen als Rechenprodukt in einer Vielfalt von Formen verteilt werden und können unabhängig vom jeweiligen Maschinentyp oder von den jeweiligen computerlesbaren Medien, die zum eigentlichen Verteilen verwendet werden, angewendet zu werden.
Wie weiter zu erkennen ist, beziehen sich die vorstehenden Offenbarungen auf spezifische beispielhafte Ausführungsformen, die in veranschaulichendem Sinn und nicht einschränkendem Sinn betrachtet werden sollen. Dennoch ist die vorliegende Erfindung zu verschiedenen anderen Ausführungsformen und Veränderungen in der Lage, wie es dem Fachmann ersichtlich sein kann, ohne dass dabei vom Wesen der vorliegenden Erfindung abgewichen wird. Demgemäß ist es offensichtlich, dass verschiedene Modifizierungen daran vorgenommen werden können, ohne dass vom breiteren Wesen und Schutzbereich der Ausführungsformen, wie in den beigefügten Ansprüchen dargelegt, abgewichen wird.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

CN 102760075 A [0003]
US 7272086 [0010]
US 20140229025 [0011]

Claims

Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin, wobei das Verfahren Folgendes umfasst: a) Installieren eines proprietären Bootloaders (001) in einem Abschnitt der nichtflüchtigen Speichereinheit; b) Ausführen des proprietären Bootloaders (001), um dadurch in Schritt (002) ein CrDe-Modul (003) und ein OS (004) auf die nichtflüchtige Speichereinheit zu laden, worin Freiraum (005) gelassen wird; c) Ausführen des CrDe-Moduls (003), um dadurch in Schritt (006) einen dedizierten Dateisatz (007) innerhalb des Freiraums (005) zu laden; d) Zurücksetzen der Karte, worin das OS (004) ausgeführt wird, um dabei in Schritt (008) ein Mastereinrichtungspatch-Modul (010) auf demselben Abschnitt der nichtflüchtigen Speichereinheit, die zuvor durch das CrDe-Modul (003) belegt war, zu überschreiben, um diesen Abschnitt der nichtflüchtigen Speichereinrichtung zu regenerieren und somit zu bewahren; e) Ausführen des Mastereinrichtungspatch-Moduls (010), um dadurch in Schritt (011) Inhalte der nichtflüchtigen Speichereinheit zu lesen, die bei dem vorhergehenden Schritt d) als ein Abbild im Herstellungsdateiformat erzielt wurden, um in einer Vorlagereproduktionsanwendung nach Wahl zu dienen.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1, wobei die nichtflüchtige Speichereinheit insbesondere ein Flashspeicher auf einer Smartcard ist.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1 und 2, wobei der Schritt (006) in einer Personalisierung der Smartcard resultiert.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1, wobei der proprietäre Bootloader (001) und das CrDe-Modul (003) unter einer Telefonbuch-Datei gruppiert sind, um dadurch Flexibilität bei der Dateigrößenzuweisung zusätzlich zum Schutz gegen unbeabsichtigte Löschung des proprietären Bootloaders (001) und des CrDe-Moduls (003) nach der Personalisierung in Schritt (006) zu erlauben.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 4, wobei die Telefonbuch- und Herstellungsdateien in jeder Instanz der Erledigung der Schritte (006) bzw. (011) aktualisiert werden.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1 und 2, wobei die Vorlagereproduktionsanwendung nach Wahl über Schritt (011) auf die Massenherstellung von Smartcards gerichtet ist.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1, wobei die nichtflüchtige Speichereinheit alternativ ausgewählt wird aus überschreibbarem Nurlesespeicher, Magnetspeicher, optischen Platten und deren Entsprechungen.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1, wobei der Abschnitt der nichtflüchtigen Speichereinheit, der bewahrt werden kann, alternativ größer, gleich oder kleiner ist als die Speichergröße der Kombination des proprietären Bootloaders (001) und des CrDe-Moduls (003).
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1 oder 8, wobei der Abschnitt der nichtflüchtigen Speichereinheit, der bewahrt werden kann, alternativ ausgewählt wird aus denen, die durch die Belegung des CrDe-Moduls (003) und des MD-Moduls (010) identifiziert sind.
Verfahren zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 1 und 5, wobei das Telefonbuch während der Personalisierung in Schritt (006) nicht aktualisiert wird, wenn ein Abschnitt der zu bewahrenden nichtflüchtigen Speichereinheit durch Belegung durch sowohl das CrDe-Modul (003) als auch das MD-Modul (010) identifiziert ist.
System zum Bewahren einer nichtflüchtigen Speichereinheit, die insbesondere ein Flashspeicher auf einer Smartcard ist, über sequenzielle Belegung durch Einzelverwendungscode-Module darin, indem das Verfahren gemäß Anspruch 1 implementiert wird, wobei das System Folgendes umfasst: a) einen proprietären Bootloader (001), der eine auf einem Computer ausführbare Routine ist, deren Ausführung innerhalb der nichtflüchtigen Speichereinheit dazu programmiert ist, um in Schritt (002) zu resultieren, worin ein oder mehrere Einzelverwendungscode-Module, die insbesondere ein CrDe-Modul (003) und OS (004) sind, auf vorbezeichnete Orte innerhalb der nichtflüchtigen Speichereinheit geladen werden, worin Freiraum (005) gelassen wird; b) einen Dateisatz (007), der für die Personalisierung der Smartcards notwendig ist; c) ein Mastereinrichtungspatch-Modul (010), das eine auf einem Computer ausführbare Routine ist, deren Ausführung innerhalb der nichtflüchtigen Speichereinheit programmiert ist, um in Schritt (011) Inhalte der nichtflüchtigen Speichereinheit zu resultieren, die bei dem vorhergehenden Schritt d) als ein Abbild erzielt wurden, um in einer Vorlagereproduktionsanwendung nach Wahl zu dienen; und d) einen Werkzeugsatz, der ferner herkömmlich implementierte, durch Computer ausführbare Routinen, einschließlich Downloader, Personalisierungswerkzeuge und Lese-Flash-Werkzeuge für die Inbetriebnahme und die Übergabe der Steuerung entsprechend der Schritte (002), (006), (009) und (011) umfasst.
System zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 6, wobei der proprietäre Bootloader (001) einen Befehlssatz enthält, der zur Durchführung von Folgendem eingerichtet ist: a) Auslöschen eines oder mehrerer Sektoren der nichtflüchtigen Speichereinheit; b) Schreiben von spezifischem Informationsinhalt auf vorbezeichnete Abschnitte der nichtflüchtigen Speichereinheit; c) Verifizieren des Erfolgs des vorhergehenden Schritts b) durch Validieren eines vorbestimmten zyklischen Redundanzprüfungswerts gegenüber dem, der intern für die nichtflüchtige Speichereinheit berechnet wurde; und d) bei erfolgreicher Erledigung des Schritts c), Übergabe der Steuerung vom proprietären Bootloader (001) an das OS (004).
System zum Bewahren einer nichtflüchtigen Speichereinheit über sequenzielle Belegung durch Einzelverwendungscode-Module darin gemäß Anspruch 6, wobei das OS (004) einen Befehlssatz enthält, der zur Durchführung von Folgendem eingerichtet ist: a) Erstellen, insbesondere des Dateisatzes (007), und Löschen von Inhalten innerhalb des Freiraums (005), der für die Personalisierung der Smartcard notwendig ist; b) Auslöschen eines oder mehrerer Sektoren der nichtflüchtigen Speichereinheit; c) Schreiben von spezifischem Informationsinhalt auf vorbezeichnete Abschnitte der nichtflüchtigen Speichereinheit; d) Verifizieren des Erfolgs des vorhergehenden Schritts b) durch Validieren eines vorbestimmten zyklischen Redundanzprüfungswerts gegenüber dem, der intern für die nichtflüchtige Speichereinheit berechnet wurde; e) Schützen der Herunterladefunktionalität des OS (004) durch Authentifizieren der vorhergehenden Schritte b) bis d); und f) bei erfolgreicher Erledigung des Schritts e), Übergabe der Steuerung vom OS (004) an das Mastereinrichtungspatch-Modul (010).