EP3218894A1 - Verfahren zum testen und zum härten von softwareapplikationen - Google Patents

Verfahren zum testen und zum härten von softwareapplikationen

Info

Publication number
EP3218894A1
EP3218894A1 EP15801327.6A EP15801327A EP3218894A1 EP 3218894 A1 EP3218894 A1 EP 3218894A1 EP 15801327 A EP15801327 A EP 15801327A EP 3218894 A1 EP3218894 A1 EP 3218894A1
Authority
EP
European Patent Office
Prior art keywords
white box
implementation
lookup table
plain
intermediate results
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP15801327.6A
Other languages
English (en)
French (fr)
Inventor
Hermann Drexler
Sven Bauer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Priority to EP20020079.8A priority Critical patent/EP3686871A1/de
Publication of EP3218894A1 publication Critical patent/EP3218894A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • G09C1/06—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system wherein elements corresponding to the signs making up the clear text are operatively connected with elements corresponding to the signs making up the ciphered text, the connections, during operation of the apparatus, being automatically and continuously permuted by a coding or key member
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4403—Processor initialisation
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/002—Countermeasures against attacks on cryptographic mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0625—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation with splitting of the data block into left and right halves, e.g. Feistel based algorithms, DES, FEAL, IDEA or KASUMI
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H04L2209/043—Masking or blinding of tables, e.g. lookup, substitution or mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/08—Randomization, e.g. dummy operations or using noise
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box

Definitions

  • the invention generally relates to the technical field of protecting software applications against attacks. More particularly, the invention relates to methods for testing, and otherwise, for hardening software applications for performing digital transactions that include a "white box" implementation of a cryptographic algorithm.
  • Mobile terminals are increasingly being used in the form of smartphones to make digital transactions, for example for cashless payments at an NFC terminal or for the purchase of a product or service from an online mail order company.
  • a software application implemented on the smartphone usually interacts with a terminal or server.
  • a cryptographic algorithm e.g. an encryption algorithm
  • security-critical data e.g. PINs, passwords, keys, etc.
  • security-critical data have generally been deposited on an independent security element of the mobile terminal in the form of a removable from the mobile terminal SIM card to protect them from attack by unauthorized persons.
  • a more recent approach, which can be advantageously used, in particular, when carrying out digital transactions with a mobile terminal that does not have an independent security element for the secure storage of security-critical data, is based on the so-called "White Box "cryptography In a” white box "implementation of a cryptographic algorithm, an attempt is made to conceal the security-critical data, in particular secret cryptographic keys, in the implementation such that an attacker who has full access to the implementation does not
  • a "white box” implementation of the AES (Advanced Encryption Standard) crypto algorithm is described, for example, in the publication "A tutorial on White Box AES” by James A. Muir, Cryptology ePrint Archive, Report 2013/104.
  • “white box” implementations of cryptographic algorithms or routines are commercially distributed.
  • the method comprises the following steps: (a) feeding a plain text of a plurality of plain texts into the white box implementation; (b) step-by-step reading and storing of the contents of the at least one register of the processor during the step-by-step execution of the machine instructions of the white box.
  • the content of a plaintext register is treated as a function of the number of processed machine instructions, analogous to a current curve in the differential current analysis.
  • the white box implementation is part of a software application for performing a digital transaction.
  • the step (d) of statistically evaluating the contents of the registers and the plain texts, the intermediate results and / or the ciphertexts generated from the plain texts comprises the evaluation by means of statistical methods known from the differential stream analysis.
  • N is chosen to be so large that a static evaluation of the contents of the registers and the plain texts, the intermediate results and / or the ciphertexts generated from the plain texts is possible.
  • steps (a) and (b) are performed with at least 10, 100 or 1000 different plaintexts.
  • step (b) the reading of the content of the at least one register is performed only from a machine instruction predefined in the "white box" implementation.
  • step (b) the reading of the content of the at least one register from the predefined machine instruction is performed for a predefined number M of machine instructions.
  • the "white box" implementation of a cryptographic algorithm is a "white box” implementation of the AES algorithm.
  • step (d) of the statistical evaluation of the contents of the registers and the plain texts the intermediate results and / or the generated from the plain texts
  • Ciphertexts such intermediate results and / or from the plain texts had used ciphertexts depending on only a few bits of the secret key.
  • a method for hardening a processor-executable white box implementation of a cryptographic algorithm capable of generating a ciphertext from a plaintext using a cryptographic key is designed in such a way that at least one lookup table is used to generate the ciphertext in order to statically map input values of the lookup table to output values of the lookup table.
  • the method includes the step of statistically permuting the lookup table such that the individual bits of the permuted lookup table are substantially uncorrelated with the bits of the lookup table.
  • the method further comprises the step of randomizing the white box implementation.
  • randomization essentially means that each time the "white box" implementation is executed, an additional, varying randomness, preferably in the form of random numbers, is interspersed.
  • another method of hardening a processor-executable "white box" implementation of a cryptographic algorithm that uses a plaintext cryptographic key is one
  • Ciphertext can produce.
  • the "white box” implementation of the At least one lookup table is used to generate the ciphertext in order to statically map input values of the lookup table to output values of the lookup table.
  • the method includes the step of randomizing the white box implementation.
  • randomizing essentially means that each time the "white box" implementation is performed, an additional, varying randomness, preferably in the form of random numbers, is interspersed.
  • the step of randomizing the "white box" implementation according to the second or third aspect of the invention comprises the step of randomly scrambling the program flow of the "white box" implementation.
  • the step of randomizing the "white box" implementation according to the second or third aspect of the invention comprises the step of introducing functionally equivalent code variants from which, in the implementation of the "white box” implementation, one random the code variants can be selected.
  • the step of randomizing the white box implementation according to the second or third aspect of the invention comprises the step of randomly masking intermediate results, input data and / or output data.
  • the step of randomizing the "white box" implementation according to the second or third aspect of the invention comprises the step of introducing accidental changes that are falling out of operations in the white box implementation.
  • the step of randomizing the "white box" implementation according to the second or third aspect of the invention comprises the step of randomizing tabulated functions.
  • the step of randomizing the "white box" implementation according to the second or third aspect of the invention comprises the step of replacing in the
  • “White Box” implementation used lookup tables through several functionally equivalent variants of lookup tables, whereby when executing the "white box” implementation, one of the functionally equivalent variants of lookup tables can be randomly selected.
  • the variants of lookup tables are preferably permutated statistically in such a way that the individual bits of the permuted lookup table essentially do not correlate with the bits of the original lookup table.
  • FIG. 1 shows a schematic representation of an exemplary communication system with a mobile terminal, in which the present invention can be advantageously used
  • FIG. 2 is a flowchart showing the flow of a method for testing a digital transaction software application in accordance with a preferred embodiment that includes a white box implementation of a cryptographic algorithm and is implemented on the mobile terminal of FIG 3 is a flow chart showing the flow of a method for curing a digital transaction software application in accordance with a preferred embodiment that includes a white box implementation of a cryptographic algorithm and on the mobile terminal of FIG is implemented.
  • FIG. 1 shows a schematic representation of an exemplary communication system 10, in which the invention can be used advantageously.
  • the communication system 10 comprises a computer unit 20 in the form of a mobile terminal, preferably in the form of a smartphone.
  • the mobile terminal 20 is configured to communicate with a server or terminal 60 via a communication channel 50.
  • the communication channel 50 may be, for example, the Internet, a mobile radio network, an NFC channel or the like.
  • the Server 60 could be a NFC terminal of a service provider, with which a software application 26b on the mobile terminal 20 can perform transactions, for example a payment transaction, in which the software application handles a payment transaction.
  • the mobile terminal 20 has a chip 22 having a central processing unit (CPU) in the form of a microprocessor 24, for example.
  • CPU central processing unit
  • the primary tasks of the processor 24 include performing arithmetic and logic functions and reading and writing of data elements, as defined by a software application running on the processor 24 in the form of machine instructions.
  • the processor 24 in the embodiment shown in FIG. 1 comprises an arithmetic unit 30 and a control unit 40.
  • the arithmetic unit 30 of the processor 24 preferably consists essentially of an arithmetic logic unit (ALU) 32 and a plurality of working or data registers, of which in FIG. 1, by way of example, three registers, namely the registers R0, Rl and R2 are shown and designated by the reference numerals 34, 36 and 38.
  • ALU arithmetic logic unit
  • the arithmetic unit 30 will have more (as indicated by the dots in Figure 1) than the three registers R0, R1 and R2 shown in Figure 4, for example four, eight, sixteen or more registers.
  • the arithmetic unit 30 is essentially configured to link together data elements in accordance with the machine commands of the software application executed by the processor 24 by means of the ALU 32 and to store the results of such links, for example in the registers R0, Rl or R2 for further processing.
  • the registers RO, Rl and R2 serve as an accumulator for the ALU 32.
  • the control unit 40 of the processor 24 is known to essentially serve to control the operation of the arithmetic unit 30 and optionally other components of the processor 24 on the basis of the successive processing of the machine commands a running on the processor 24 software application.
  • the control unit 40 of the processor 24 also comprises a plurality of registers, preferably a program counter (PC) 42, an instruction register (IR) 44, a status register (SR). 46 and a stack pointer (SP) 48.
  • PC program counter
  • IR instruction register
  • SR status register
  • SP stack pointer
  • the instruction counter PC usually contains in each case the memory address of the next machine instruction to be executed by the software application running on the processor 24.
  • the currently executing machine command is stored in the command register IR.
  • the status register SR is configured to receive feedback messages from the arithmetic unit 30 and the control unit 40, which can influence the address advance in the software application executed by the processor 24.
  • the stack register SP 48 of the control unit 40 of the processor 24 is used to manage a stack (also called "stack"), which may be implemented in a memory unit 26 of the mobile terminal 20.
  • the stack register SP 48 of the control unit 40 usually contains the memory address which defines the variable end of the stack in the memory unit 26.
  • the memory unit 26 which is in communication with the processor 24, may preferably provide volatile random access memory (RAM), for example, for receiving the machine instructions from the processor 24 to be executed software application.
  • the memory unit 26 may comprise a non-volatile, preferably rewritable memory in order, for example, to receive the machine instructions of a software application to be executed by the processor 24 in the de-energized state.
  • the non-volatile, rewritable memory is a flash memory (flash EEPROM). This may be, for example, a flash memory with a NAND or a NOR architecture.
  • the memory unit 26 can also comprise a read-only memory (ROM).
  • FIG. 1 schematically shows that a software application 26 a for carrying out a digital transaction of the mobile terminal 10 with the server 60 is stored on the storage unit 26.
  • the software application 26a comprises a "white box” implementation of a cryptographic algorithm, for example a "white box” implementation of the AES algorithm, which is identified in FIG. 1 by the reference numeral 26b.
  • the "white box” implementation 26b is designed to generate a ciphertext from a plaintext text by means of a (i.e., secret) cryptographic key hidden in the "white box” implementation 26b.
  • step S1 of FIG. 2 the white box implementation 26b to be tested (or the software application 26a, which includes the white box implementation 26b to be tested, 26) becomes a first known one Plain text is provided as input to be encrypted by the "white box" implementation 26b by means of the secret key hidden therein, ie to generate a corresponding ciphertext.
  • step S2 of FIG. 2 the step-by-step processing of the machine instructions deposited on the memory unit 26 and the white box implementation 26b (or the software application 26a comprising the white box implementation 26b to be tested 26b) define, step by step, the contents of the registers R0, Rl, R2, ... of the processor 24 read out and stored. Preferably, all data registers of the processor 24 are read out.
  • the reading out and storage of the register contents could be carried out, for example, by means of a debugger.
  • the register contents are read out and stored at each step, ie after every command.
  • processing the machine instructions step by step to generate a ciphertext from the plain text one or more intermediate results may arise.
  • the step-by-step readout and storage of the register contents of the processor 24 only starts from a definable machine command in the software application 26a is performed (similar to a breakpoint during debugging).
  • the final result of the step-by-step execution of the machine instructions of the white box implementation 26b is a ciphertext associated with the plaintext input in step S1, which is output from the white box implementation 26b in step S3.
  • the ciphertext and / or the associated plaintext stored in connection with the already stored in step S2 after each execution of a machine command register contents of the processor 24.
  • certain intermediate results calculated during the generation of the ciphertext can be stored.
  • the steps S1 to S3 of FIG. 2 are carried out or repeated for a multiplicity of plain texts (see step S4 of FIG. 2).
  • the steps S1 to S3 of FIG. 2 are carried out or repeated for more than 10, more than 100 or more than 1000 different plain texts.
  • a respective record is obtained which includes the register contents of the processor 24 for the respective machine instructions of the white box implementation 26b, the input plaintext, selected intermediate results and the associated ciphertext ,
  • step S5 of FIG. 2 the data records obtained by means of steps S1 to S4 are evaluated in order to obtain information about the key used for generating the ciphertexts from the respective plain texts of the "white box" implementation 26b.
  • statistical methods are used for this purpose, as are known from differential power analysis (DPA), which is known to be a form of side channel attacks on chip cards.
  • DPA differential power analysis
  • the statistical methods which are known from the differential current analysis of cryptographic algorithms implemented on chip cards can be used particularly advantageously in that the content of a register of the processor as a function of the number of machine instructions already processed, such as a current curve (current profile as function the machine command or the time) is treated in the differential current analysis.
  • the attacker assumes that he has correctly determined the partial key value. If no significant correlations are found for this subkey, the attacker chooses a different value for the subkey. If no correlations are found for any value of the subkey, the attack on the subkey will fail. If the computational step to be accessed has been chosen deftly, the subkey entering the bill is so short that the attacker can try out all possible values for the subkey. Once the attacker successfully determines a portion of the key, he applies the same technique to identify other key pieces. He can also use the fact that some key parts have already been determined successfully.
  • the keys hidden in the white box implementation 26b can be determined by looking for correlations between the register contents and the plain texts, the intermediate results generated in the calculation, and / or the generated ciphertexts.
  • such intermediate results generated in the calculation of a ciphertext are suitable here, which depend only on a few bits of the key.
  • the inventors have succeeded, using a few hundred plaintexts described in connection with FIG extract the hidden key from the "white box” implementation.
  • the attack used on the runs White box implementation of the AES algorithm as follows.
  • the attacker collects eg for 200 different plain texts the register contents. He then selects a location in the AES where only a few bits of the secret key have entered the result, such as the output of the first S-Box lookup. As is known to those skilled in the art, this depends on a byte of the key and a byte of the plaintext. Now the attacker advises a value for this one byte of the key.
  • a suitable statistical permutation of a lookup table is understood here as a permutation in which the individual bits of the permuted lookup table do not correlate with the bits of the original lookup table.
  • FIG. 3 shows in the form of a flowchart a preferred embodiment of a method for hardening the "white box" implementation 26b of FIG.
  • a look-up table is located in the white box implementation 26b.
  • step S11 of FIG. 3 may be performed for further, preferably all, lookup tables of the white box implementation 26b.
  • step S11 of FIG. 3 may be performed for further, preferably all, lookup tables of the white box implementation 26b.
  • further measures can be taken in a step S13 to fend off or at least aggravate the attack depicted in FIG.
  • these further measures may be described as randomizing into or as "randomizing" the white box implementation 26b.
  • randomization essentially means that with each execution of the "white box” implementation 26b, an additional, varying random, preferably in the form of random numbers, is interspersed.
  • the program flow of the "white box” implementation 26b can be randomly scrambled. For this, portions of the "white box” implementation 26b that can be parallelized are executed in random order. The order for each run, i. for each new plaintext, newly generated randomly. As is known to those skilled in the art, for example, the S-box lookup can be parallelized in an implementation of the AES algorithm.
  • Code variants can be introduced into the "white box” implementation 26b, with the code variants providing the same functionality despite different program execution. When executing the "white box” implementation, one of these functionally equivalent code variants can then be randomly selected. 3.
  • the "white box” implementation 26b may be modified to randomly mask intermediate results, input data and / or output data. For this purpose, the intermediate results, input data and / or output data are decomposed as a sum, each summand being random.
  • Lookup tables are replaced.
  • these variants of lookup tables are preferably hardened according to the step S 1 shown in FIG. 3 and described above, ie. is statistically permuted such that the individual bits of the permuted lookup table are substantially uncorrelated with the bits of the original lookup table.
  • one of the functionally equivalent variants of lookup tables can be chosen at random.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)

Abstract

Es werden Verfahren zum einen zum Testen von und zum anderen zum Härten von Softwareapplikationen zum Durchführen von digitalen Transaktionen bereitgestellt, die eine "White Box"-Implementierung eines kryptographischen Algorithmus umfassen. Das Verfahren zum Testen einer "White Box"-Implementierung eines kryptographischen Algorithmus, die mittels eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugt und auf einem Prozessor mit wenigstens einem Register in Form von Maschinenbefehlen vorliegt, umfasst die folgenden Schritte: (a) das Einspeisen eines Plaintexts einer Vielzahl von Plaintexten in die "White Box"- Implementierung; (b) das schrittweise Auslesen und Abspeichern des Inhalts des wenigstens einen Registers des Prozessors beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"-Implementierung, wobei beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"- Implementierung Zwischenergebnisse erzeugt werden können; (c) das N-malige Wiederholen der Schritte (a) und (b) mit einem weiteren Plaintext der Vielzahl von Plaintexten; und (d) das statistische Auswerten der Inhalte der Register und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte, indem nach Korrelationen zwischen den Inhalten der Register und den Plaintexten, den Zwischenergebnissen und/ oder den Ciphertexten gesucht wird, um den geheimen Schlüssel zu ermitteln.

Description

Verfahren zum Testen und zum Härten
von Softwareapplikationen
Gebiet der Erfindung
Die Erfindung betrifft allgemein das technische Gebiet des Schützens von Softwareapplikationen gegen Angriffe. Insbesondere betrifft die Erfindung Verfahren zum einen zum Testen von und zum anderen zum Härten von Softwareapplikationen zum Durchführen von digitalen Transaktionen, die eine "White Box"-Implementierung eines kryptographischen Algorithmus umfassen.
Hintergrund der Erfindung
Mehr und mehr werden mobile Endgeräte in Form von Smartphones dazu verwendet, digitale Transaktionen durchzuführen, beispielsweise zum bargeldlosen Bezahlen an einem NFC-Terminal oder zum Kauf einer Ware oder einer Dienstleistung bei einem Online- Versandhändler. Bei der Durchführung einer solchen digitalen Transaktion interagiert in der Regel eine auf dem Smartphone implementierte Softwareapplikation (kurz " App" genannt) mit einem Terminal bzw. Server. Dabei ist häufig ein kryptographischer Algorithmus, z.B. ein Verschlüsselungsalgorithmus, Teil der auf dem mobilen Endgerät implementierten Softwareapplikation, die auf sicherheitskritische Daten, z.B. PINs, Passwörter, Schlüssel etc., zugreift. In der Vergangenheit sind sicherheitskritische Daten in der Regel auf einem eigenständigen Sicherheitselement des mobilen Endgeräts häufig in Form einer aus dem mobilen Endgerät herausnehmbaren SIM-Karte hinterlegt worden, um diese vor einem Angriff durch unbefugte Person zu schützen.
Ein neuerer Ansatz, der insbesondere bei der Durchführung von digitalen Transaktionen mit einem mobilen Endgerät vorteilhaft eingesetzt werden kann, dass kein eigenständiges Sicherheitselement zum sicheren Speichern von sicherheitskritischen Daten aufweist, basiert auf der sogenannten "White Box"-Kryptographie. Bei einer "White Box"-Implementierung eines kryptographischen Algorithmus wird versucht, die sicherheitskritischen Daten, insbesondere geheime kryptographische Schlüssel, derart in der Implementierung zu verbergen, dass ein Angreifer, der vollen Zugriff auf die Imple- mentierung hat, nicht dazu in der Lage ist, die sicherheitskritischen Daten aus dieser zu extrahieren. Eine "White Box"-Implementierung des AES- Kryptoalgorithmus ("Advanced Encryption Standard") ist beispielsweise aus der Veröffentlichung " A Tutorial on White-box AES" von James A. Muir, Cryptology ePrint Archive, Report 2013/104 bekannt. Ebenso werden "Whi- te Box"-Implementierungen von kryptographischen Algorithmen bzw. Routinen kommerziell vertrieben.
Der Erfindung liegt die Aufgabe zugrunde, Verfahren zum einen zum Testen von und zum anderen zum Härten von Softwareapplikationen zum Durch- führen von digitalen Transaktionen bereitzustellen, die eine "White Box"- Implementierung eines kryptographischen Algorithmus umfassen.
Zusammenfassung der Erfindung
Die vorstehenden Aufgaben werden gemäß der vorliegenden Erfindung durch die jeweiligen Gegenstände der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen der Erfindung werden in den abhängigen Ansprüchen definiert.
Überraschenderweise hat sich bei den Untersuchungen der Erfinder gezeigt, dass sich bei kommerziell erhältlichen "White Box"-Implementierungen von kryptographischen Algorithmen bzw. Routinen der geheime Schlüssel ableiten lässt, und zwar mittels des folgenden Verfahrens gemäß einem ersten Aspekt der Erfindung. Gemäß einem ersten Aspekt der Erfindung wird ein Verfahren zum Testen einer auf einem Prozessor ausführbaren "White Box"-Implementierung eines kryptographischen Algorithmus bereitgestellt, die mittels eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugt und auf dem Prozes- sor in Form von Maschinenbefehlen vorliegt, wobei der Prozessor wenigstens ein Register umf asst. Dabei umfasst das Verfahren die folgenden Schritte: (a) das Einspeisen eines Plaintexts einer Vielzahl von Plaintexten in die "White Box"-Implementierung; (b) das schrittweise Auslesen und Abspeichern des Inhalts des wenigstens einen Registers des Prozessors beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"-
Implementierung, wobei beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"-Implementierung Zwischenergebnisse erzeugt werden können; (c) das N-malige Wiederholen der Schritte (a) und (b) mit einem weiteren Plaintext der Vielzahl von Plaintexten; und (d) das statistische Auswer- ten der Inhalte der Register und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte, indem nach Korrelationen zwischen den Inhalten der Register und den Plaintexten, den Zwischenergebnissen und/ oder den Ciphertexten gesucht wird, um den geheimen Schlüssel zu ermitteln.
Vorzugsweise wird der Inhalt eines Registers für einen Plaintext als Funktion der Anzahl der abgearbeiteten Maschinenbefehle analog zu einer Stromkurve bei der differentiellen Stromanalyse behandelt. Gemäß bevorzugter Ausführungsformen der Erfindung ist die "White Box"- Implementierung Teil einer Softwareapplikation zum Durchführen einer digitalen Transaktion. Vorzugsweise umfasst der Schritt (d) des statistischen Auswertens der Inhalte der Register und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte das Auswerten mittels statistischer Verfahren, die aus der differentiellen Stromanalyse bekannt sind.
Gemäß bevorzugter Ausführungsformen der Erfindung ist N derart groß gewählt, dass ein statisches Auswerten der Inhalte der Register und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte möglich ist. Vorzugsweise werden die Schritte (a) und (b) mit wenigstens 10, 100 oder 1000 unterschiedlichen Plaintexten durchgeführt.
Vorzugsweise wird beim Schritt (b) das Auslesen des Inhalts des wenigstens einen Registers erst ab einem in der "White Box"-Implementierung vordefi- nierten Maschinenbefehl durchgeführt.
Gemäß bevorzugter Ausführungsformen der Erfindung wird beim Schritt (b) das Auslesen des Inhalts des wenigstens einen Registers ab dem vordefinierten Maschinenbefehl für eine vordefinierte Anzahl M von Maschinenbe- fehlen durchgeführt.
Vorzugsweise handelt es sich bei der "White Box"-Implementierung eines kryptographischen Algorithmus um eine "White Box"-Implementierung des AES- Algorithmus .
Gemäß bevorzugter Ausführungsformen der Erfindung werden beim Schritt (d) des statistischen Auswertens der Inhalte der Register und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten
Ciphertexte solche Zwischenergebnisse und/ oder aus den Plaintexten er- zeugte Ciphertexte verwendet, die von nur wenigen Bits des geheimen Schlüssels abhängen.
Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren zum Härten einer auf einem Prozessor ausführbaren "White Box"-Implementierung eines kryptographischen Algorithmus bereitgestellt, die unter Verwendung eines kryptographischen Schlüssels aus einem Plaintext einen Ciphertext erzeugen kann. Dabei ist die "White Box "-Implementierung derart ausgestaltet, dass bei der Erzeugung des Ciphertextes wenigstens eine Lookup-Tabelle zum Einsatz kommt, um statisch Eingabewerte der Lookup-Tabelle auf Ausgabewerte der Lookup-Tabelle abzubilden. Das Verfahren umfasst den Schritt, dass die Lookup-Tabelle derart statistisch permutiert wird, dass die einzelnen Bits der permutierten Lookup-Tabelle im Wesentlichen nicht mit den Bits der Lookup-Tabelle korrelieren. Mit anderen Worten: die Lookup- Tabelle T wird derart mittels einer Permutation P statistisch permutiert, dass die einzelnen Bits der permutierten Lookup-Tabelle T'(x) = P(T(x)) bei zufällig variierendem Input x nicht mit den Bits T(x) korrelieren.
Vorzugsweise umfasst das Verfahren ferner den Schritt des Randomisierens der "White Box"-Implementierung. Hierbei wird unter "Randomisieren" im Wesentlichen verstanden, dass bei jeder Ausführung der "White Box"- Implementierung ein zusätzlicher, variierender Zufall, vorzugsweise in Form von Zufallszahlen, eingestreut wird.
Gemäß einem dritten Aspekt der Erfindung wird ein weiteres Verfahren zum Härten einer auf einem Prozessor ausführbaren "White Box"- Implementierüng eines kryptographischen Algorithmus, die unter Verwendung eines kryptographischen Schlüssels aus einem Plaintext einen
Ciphertext erzeugen kann. Dabei ist die "White Box"-Implementierung der- art ausgestaltet, dass bei der Erzeugung des Ciphertextes wenigstens eine Lookup-Tabelle zum Einsatz kommt, um statisch Eingabewerte der Lookup- Tabelle auf Ausgabewerte der Lookup-Tabelle abzubilden. Das Verfahren umfasst den Schritt des Randomisierens der "White Box"-Implementierung. Hierbei wird unter "Randomisieren" im Wesentlichen verstanden, dass bei jeder Ausführung der "White Box"-Implementierung ein zusätzlicher, variierender Zufall, vorzugsweise in Form von Zufallszahlen, eingestreut wird.
Vorzugsweise umfasst der Schritt des Randomisierens der "White Box"- Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des zufälligen Verwürfeins des Programmablaufs der "White Box " -Implementierung.
Gemäß bevorzugter Ausführungsformen der Erfindung umfasst der Schritt des Randomisierens der "White Box"-Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des Einbringens von funktional äquivalenten Code- Varianten, aus denen bei der Ausführung der "White Box"-Implementierung zufällig eine der Code-Varianten ausgewählt werden kann.
Vorzugsweise umfasst der Schritt des Randomisierens der "White Box"- Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des zufälligen Maskierens von Zwischenergebnissen, Eingabedaten und/ oder Ausgabedaten.
Gemäß bevorzugter Ausführungsformen der Erfindung umfasst der Schritt des Randomisierens der "White Box"-Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des Einbringens von zufälli- gen Veränderungen, die bei den in der "White Box"-Implementierung vorgenommenen Operationen wieder herausfallen.
Vorzugsweise umfasst der Schritt des Randomisierens der "White Box"- Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des Randomisierens von tabellierten Funktionen.
Gemäß bevorzugter Ausführungsformen der Erfindung umfasst der Schritt des Randomisierens der "White Box"-Implementierung gemäß dem zweiten oder dritten Aspekt der Erfindung den Schritt des Ersetzens von in der
"White Box"-Implementierung verwendeten Lookup-Tabellen durch mehrere funktional äquivalente Varianten von Lookup-Tabellen, wobei bei der Durchführung der "White Box"-Implementierung jeweils eine der funktional äquivalenten Varianten von Lookup-Tabellen zufällig ausgewählt werden kann. Dabei werden die Varianten von Lookup-Tabellen vorzugsweise statistisch derart permutiert, dass die einzelnen Bits der permutierten Lookup- Tabelle im Wesentlichen nicht mit den Bits der ursprünglichen Lookup- Tabelle korrelieren. Gemäß einem vierten Aspekt der Erfindung wird eine "White Box"-
Implementierung eines kryptographischen Algorithmus bereitgestellt, die unter Verwendung eines kryptografischen Schlüssels aus einem Plaintext einen Ciphertext erzeugen kann, wobei die "White Box"-Implementierung mit einem Verfahren gemäß dem zweiten oder dritten Aspekt der Erfindung gehärtet worden ist.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden detaillierten Beschreibung mehrerer Ausführungsbeispiele und Aus- führungsalternativen hervor. Es wird auf die Zeichnungen verwiesen, in denen zeigen: eine schematische Darstellung eines beispielhaften Kommunikationssystems mit einem mobilen Endgerät, bei dem die vorliegende Erfindung vorteilhaft zum Einsatz kommen kann,
Fig. 2 ein Flussdiagramm, das den Ablauf eines Verfahrens zum Testen einer Softwareapplikation zum Durchführen von digitalen Transaktionen gemäß einer bevorzugten Ausführungsform zeigt, die eine "White Box"-Implementierung eines kryptogra- phischen Algorithmus umfasst und auf dem mobilen Endgerät von Figur 1 implementiert ist, und Fig. 3 ein Flussdiagramm, das den Ablauf eines Verfahrens zum Härten einer Softwareapplikation zum Durchführen von digitalen Transaktionen gemäß einer bevorzugten Ausführungsform zeigt, die eine "White Box"-Implementierung einer kryptogra- phischen Algorithmus umfasst und auf dem mobilen Endgerät von Figur 1 implementiert ist.
Figur 1 zeigt eine schematische Darstellung eines beispielhaften Kommunikationssystems 10, bei dem die Erfindung vorteilhaft zum Einsatz kommen kann. Das Kommunikationssystem 10 umfasst eine Computereinheit 20 in Form eines mobilen Endgeräts, vorzugsweise in Form eines Smartphones. Das mobile Endgerät 20 ist dazu ausgestaltet, über einen Kommunikationskanal 50 mit einem Server bzw. einem Terminal 60 zu kommunizieren. Bei dem Kommunikationskanal 50 kann es sich beispielsweise um das Internet, ein Mobilfunknetzwerk, einen NFC-Kanal oder dergleichen handeln. Der Server 60 könnte ein NFC-Terminal eines Service- Anbieters sein, mit dem eine Softwareapplikation 26b auf dem mobilen Endgerät 20 Transaktionen durchführen kann, z.B. eine Payment-Transaktion, bei dem die Softwareapplikation einen Bezahlvorgang abwickelt.
Das mobile Endgerät 20 verfügt über einen Chip 22 mit einer zentralen Verarbeitungseinheit ("central processing unit"; CPU) beispielsweise in Form eines Mikroprozessors 24. Bekanntermaßen gehören zu den primären Aufgaben des Prozessors 24 das Ausführen von arithmetischen und logischen Funktionen und das Lesen und Schreiben von Datenelementen, wie dies durch eine auf dem Prozessor 24 ablaufende Softwareapplikation in Form von Maschinenbefehlen definiert wird. Hierzu umfasst der Prozessor 24 bei der in Figur 1 dargestellten Ausführungsform ein Rechenwerk 30 sowie ein Steuerwerk 40.
Das Rechenwerk 30 des Prozessors 24 besteht vorzugsweise im Wesentlichen aus einer arithmetisch-logischen Einheit ("arithmetic logic unit"; ALU) 32 sowie mehreren Arbeits- bzw. Datenregistern, von denen in Figur 1 beispielhaft drei Register, nämlich die Register R0, Rl und R2 dargestellt sind und mit den Bezugszeichen 34, 36 und 38 gekennzeichnet sind. In der Regel wird das Rechenwerk 30 jedoch mehr (wie durch die Punkte in Figur 1 angedeutet) als die in Figur dargestellten drei Register R0, Rl und R2 aufweisen, beispielsweise vier, acht, sechzehn oder mehr Register. Das Rechenwerk 30 ist bekanntermaßen im Wesentlichen dazu ausgestaltet, mittels der ALU 32 Datenelemente gemäß den Maschinenbefehlen der von dem Prozessor 24 ausgeführten Softwareapplikation miteinander zu verknüpfen und die Ergebnisse derartiger Verknüpfungen beispielsweise in den Registern R0, Rl oder R2 zur Weiterverarbeitung abzulegen. Hierbei kann beispielsweise wenigs- tens eines der Register RO, Rl und R2 als Akkumulator für die ALU 32 dienen.
Das Steuerwerk 40 des Prozessors 24 dient bekanntermaßen im Wesentlichen dazu, die Arbeitsweise des Rechenwerks 30 und gegebenenfalls weiterer Komponenten des Prozessors 24 auf Basis der sukzessiven Abarbeitung der Maschinenbefehle einer auf dem Prozessor 24 ablaufenden Softwareapplikation zu steuern. Hierzu umfasst ebenso das Steuerwerk 40 des Prozessors 24 mehrere Register, und zwar vorzugsweise insbesondere einen Befehlszähler ("program counter"; PC) 42, ein Befehlsregister ("Instruction register"; IR) 44, ein Statusregister ("status register"; SR) 46 sowie ein Stapelregister ("stack pointer"; SP) 48.
Der Befehlszähler PC enthält in der Regel jeweils die Speicheradresse des nächsten auszuführenden Maschinenbefehls der auf dem Prozessor 24 ablaufenden Softwareapplikation. Der aktuell auszuführende Maschinenbefehl ist im Befehlsregister IR hinterlegt. Das Statusregister SR ist dazu ausgestaltet, Rückmeldungen aus dem Rechenwerk 30 und dem Steuerwerk 40 aufzunehmen, welche die Adressfortschaltung in der von dem Prozessor 24 ausge- führten Softwareapplikation beeinflussen können. Das Stapelregister SP 48 des Steuerwerks 40 des Prozessors 24 dient zur Verwaltung eines Stapelspeichers (auch "Stack" genannt), der in einer Speichereinheit 26 des mobilen Endgeräts 20 implementiert sein kann. Hierzu enthält das Stapelregister SP 48 des Steuerwerks 40 üblicherweise die Speicheradresse, die das variable Ende des Stapelspeichers in der Speichereinheit 26 definiert.
Die Speichereinheit 26, die in Kommunikationsverbindung mit dem Prozessor 24 steht, kann vorzugsweise einen flüchtigen Arbeitsspeicher (RAM) beispielsweise zur Aufnahme der Maschinenbefehle einer von dem Prozessor 24 auszuführenden Softwareapplikation umfassen. Ferner kann die Speichereinheit 26 einen nichtflüchtigen, vorzugsweise wieder beschreibbaren Speicher umfassen, um beispielsweise im unbestromten Zustand die Maschinenbefehle einer von dem Prozessor 24 auszuführenden Softwareappli- kation aufzunehmen. Vorzugsweise handelt es sich bei dem nichtflüchtigen, wieder beschreibbaren Speicher um einen Flash-Speicher (Flash-EEPROM). Dabei kann es sich beispielsweise um einen Flash-Speicher mit einer NAND- oder einer NOR- Architektur handeln. Selbstverständlich kann die Speichereinheit 26 auch einen Festwertspeicher ("read only memory"; ROM) umfas- sen.
In Figur 1 ist schematisch dargestellt, dass eine Softwareapplikation 26a zum Durchführen einer digitalen Transaktion des mobilen Endgeräts 10 mit dem Server 60 auf der Speichereinheit 26 hinterlegt ist. Erfindungsgemäß umf asst die Softwareapplikation 26a eine "White Box"-Implementierung eines kryp- tographischen Algorithmus, beispielsweise eine "White Box"- Implementierung des AES- Algorithmus, die in Figur 1 mit der Bezugsziffer 26b gekennzeichnet ist. Dabei ist die "White Box"-Implementierung 26b dazu ausgestaltet, mittels eines in der "White Box"-Implementierung 26b verbor- genen (d.h. geheimen) kryptographischen Schlüssels aus einem Plaintext einen Ciphertext zu erzeugen.
Unter weiterer Bezugnahme auf Figur 2 wird nachstehend eine bevorzugte Ausführungsform eines Verfahrens zum Testen der "White Box"- Implementierung 26b von Figur 1 beschrieben.
In Schritt Sl von Figur 2 wird der zu testenden "White Box"- Implementierung 26b (bzw. der Softwareapplikation 26a, welche die zu testende "White Box"-Implementierung 26b umfasst,) ein erster bekannter Plaintext als Input bereitgestellt, um von der "White Box"-Implementierung 26b mittels des darin verborgenen geheimen Schlüssels verschlüsselt zu werden, d.h. einen entsprechenden Ciphertext zu erzeugen. In Schritt S2 von Figur 2 wird beim schrittweise Abarbeiten der Maschinebefehle, die auf der Speichereinheit 26 hinterlegt sind und die "White Box"- Implementierung 26b (bzw. die Softwareapplikation 26a, welche die zu testende "White Box"-Implementierung 26b umfasst,) definieren, schrittweise die Inhalte der Register R0, Rl, R2, ... des Prozessors 24 ausgelesen und ab- gespeichert. Vorzugsweise werden dabei alle Datenregister des Prozessors 24 ausgelesen. Wie dies dem Fachmann bekannt ist, könnte das Auslesen und Abspeichern der Registerinhalte beispielsweise mittels eines Debuggers durchgeführt werden. Vorzugsweise werden die Registerinhalte bei jedem Schritt, d.h. nach jedem Befehl, ausgelesen und abgespeichert. Beim schrittweise Abarbeiten der Maschinebefehle zur Erzeugung eines Ciphertextes aus dem Plaintext können eine oder mehrere Zwischenergebnisse entstehen.
Insbesondere für den Fall, dass die "White Box"-Implementierung 26b eines kryptographischen Algorithmus Teil einer umfangreichen Softwareapplikation 26a ist, kann es erfindungsgemäß vorteilhaft sein, dass das schrittweise Auslesen und Abspeichern der Registerinhalte des Prozessors 24 erst ab einem definierbaren Maschinenbefehl in der Softwareapplikation 26a durchgeführt wird (vergleichbar einem Haltepunkt ("breakpoint") beim Debuggen).
Wie bereits vorstehend erwähnt, ist das Endergebnis der schrittweisen Abarbeitung der Maschinenbefehle der "White Box"-Implementierung 26b ein zu dem in Schritt Sl eingegebenen Plaintext dazugehöriger Ciphertext, der in Schritt S3 von der "White Box "-Implementierung 26b ausgegeben wird. Vorzugsweise werden der Ciphertext und/ oder der dazugehörige Plaintext in Verbindung mit den bereits in Schritt S2 nach jeder Abarbeitung eines Maschinenbefehls gespeicherten Registerinhalten des Prozessors 24 abgespeichert. Überdies können bestimmte bei der Erzeugung des Ciphertextes berechnete Zwischenergebnisse abgespeichert werden.
Erfindungsgemäß werden die Schritte Sl bis S3 von Figur 2 für eine Vielzahl von Plaintexten durchgeführt bzw. wiederholt (siehe Schritt S4 von Figur 2). Vorzugsweise werden die Schritte Sl bis S3 von Figur 2 für mehr als 10, mehr als 100 oder mehr als 1000 unterschiedliche Plaintexte durchgeführt bzw. wiederholt. Wie der Fachmann erkennt, erhält man so für jede Wiederholung der Schritte Sl bis S3 einen jeweiligen Datensatz, der die Registerinhalte des Prozessors 24 zu den jeweiligen Maschinenbefehlen der "White Box"-Implementierung 26b, den eingegebenen Plaintext, ausgewählte Zwischenergebnisse und den dazugehörigen Ciphertext umfasst.
In Schritt S5 von Figur 2 werden die mittels der Schritte Sl bis S4 gewonnenen Datensätze ausgewertet, um Informationen über den für die Erzeugung der Ciphertexte aus den jeweiligen Plaintexten von der "White Box"- Implementierung 26b verwendeten Schlüssel zu gewinnen. Erfindungsge- mäß werden hierzu statistische Verfahren angewendet, wie diese aus der differentiellen Stromanalyse ("Differential Power Analysis"; DPA) bekannt sind, bei der es sich bekanntermaßen um eine Form von Seitenkanalangriffen auf Chipkarten handelt. Erfindungsgemäß lassen sich die statistischen Verfahren, die aus der differentiellen Stromanalyse von auf Chipkarten imple- mentierten kryptographischen Algorithmen bekannt sind, besonders vorteilhaft dadurch anwenden, dass der Inhalt eines Registers des Prozessors als Funktion der Anzahl der bereits abgearbeiteten Maschinenbefehle wie eine Stromkurve (Stromverlauf als Funktion des Maschinenbefehls bzw. der Zeit) bei der differentiellen Stromanalyse behandelt wird. Wie dies dem Fachmann bekannt ist, sucht ein Angreifer bei der diff erentiel- len Stromanalyse für einen geratenen Teil des geheimen Schlüssels in den Stromkurven nach Korrelationen zwischen der Stromaufnahme und Zwischenergebnissen, die für diesen Teilschlüssel und bekannte Piain- oder Cipher texte berechnet worden sind. Der Angreifer nimmt also an, dass ein Teil des Schlüssel (z.B. ein Byte) einen bestimmten Wert hat und wählt dann einen Rechenschritt im Kryptoalgorithmus, dessen Ergebnis nur von diesem Teil des Schlüssels sowie bekannten Piain- oder Ciphertextdaten abhängt. Für diesen festen Teilschlüsselwert und variierende Piain- oder Ciphertext- daten berechnet er dann das Ergebnis des angegriffenen Rechenschrittes. Findet er signifikante Korrelationen zwischen den berechneten Daten und der bei der Bearbeitung der selben Piain- oder Ciphertextdaten aufgezeichneten Stromaufnahme des angegriffenen Gerätes, dann geht der Angreifer davon aus, dass er den Teilschlüsselwert korrekt bestimmt hat. Finden sich keine signifikanten Korrelationen für diesen Teilschlüssel wert, so wählt der Angreifer einen anderen Wert für den Teilschlüssel. Finden sich für keinen Wert des Teilschlüssels Korrelationen, so schlägt der Angriff auf den Teilschlüssel fehl. Wurde der anzugreifende Rechenschritt geschickt gewählt, ist der in die Rechnung eingehende Teilschlüssel so kurz, dass der Angreifer alle für den Teilschlüssel möglichen Werte ausprobieren kann. Hat der Angreifer einen Teil des Schlüssels erfolgreich bestimmt, wendet er die gleiche Technik an, um weitere Schlüsselteile zu ermitteln. Dabei kann er auch die Tatsache nutzen, dass einige Schlüsselteile bereits erfolgreich bestimmt wurden.
Überraschenderweise hat sich gezeigt, dass bei der analogen Anwendung der aus der differentiellen Stromanalyse bekannten statistischen Verfahren im Rahmen der vorliegenden Erfindung, bei der, wie vorstehend erwähnt, der Inhalt eines Registers des Prozessors als Funktion des Maschinenbefehls wie eine Stromkurve behandelt wird, der in der "White Box"- Implementierung 26b verborgene Schlüssel ermittelt werden kann, indem nach Korrelationen zwischen den Registerinhalten und den Plaintexten, bei der Berechnung erzeugten Zwischenergebnissen und/ oder den erzeugten Ciphertexten gesucht wird. Insbesondere sind hier solche bei der Berechnung eines Ciphertextes erzeugte Zwischenergebnisse geeignet, die nur von wenigen Bits des Schlüssels abhängen.
Für weitere Details zu der differentiellen Stromanalyse und den dort einge- setzten statistischen Verfahren zur Ermittlung eines geheimen Schlüssels wird auf die Veröffentlichung "Differential Power Analysis", Paul C. Kocher, Joshua Jaffe, Benjamin Jun, Crypto 1999 verwiesen.
Die Veröffentlichung "White-Box Cryptogrpahy and an AES Implementati- on", S. Chow, P. Eisen, H. Johnson, P.C. van Oorschot bildet die wesentliche Grundlage für die aus der Literatur bekannten White Box"- Implementierungen von kryptographischen Algorithmen. In dieser Veröffentlichung wird zum Verbergen des Schlüssels in einer "White Box"- Implementierung des AES- Algorithmus die Verwendung einer Vielzahl von Lookup-Tabellen zum Abbilden einer Eingangsbitfolge auf eine Ausgangsbitfolge empfohlen. Für Details hierzu wird auf die genannte Veröffentlichung verwiesen.
Bei einer kommerziell erhältlichen "White Box"-Implementierung des AES- Algorithmus, bei der eine Vielzahl von Lookup-Tabellen verwendet werden, ist es den Erfindern mittels des vorstehend im Zusammenhang mit Figur 2 beschriebenen Verfahrens gelungen, unter Verwendung von einigen hundert Plaintexten den in der "White Box"-Implementierung verborgenen Schlüssel zu extrahieren. Im Detail verläuft der dabei verwendete Angriff auf die "White Box"-Implementierung des AES- Algorithmus folgendermaßen. Der Angreifer sammelt z.B. für 200 verschiedene Plaintexte die Registerinhalte. Dann wählt er eine Stelle im AES aus, an der nur wenige Bits des geheimen Schlüssels in das Ergebnis eingegangen sind, beispielsweise den Ausgang des ersten S-Box Lookup. Wie dies dem Fachmann bekannt ist, hängt dieser von einem Byte des Schlüssels und einem Byte des Plaintextes ab. Jetzt rät der Angreifer einen Wert für dieses eine Byte des Schlüssels. Damit rechnet er alle 200 S-Box- Ausgänge für die 200 Plaintexte aus. Jetzt prüft er, ob an irgendeiner Stelle die Registerinhalte mit diesem S-Box- Ausgang korrelieren. Falls dem so ist, hat der Angreifer vermutlich das Schlüssel-Byte richtig erraten. Falls der Angreifer keine Korrelation findet, rät er einen neuen Wert für das Schlüssel-Byte und wiederholt den Vorgang. In diesem Beispiel muss der Angreifer also schlimmstenfalls alle Werte für ein Byte ausprobieren, d.h. 256 mögliche Kombinationen, was mit verhältnismäßig geringem Aufwand durchführbar ist. Wie der Fachmann erkennt, ist bei Zwischenergebnissen, die von mehr als einem Byte des Schlüssels abhängen, der Aufwand entsprechend größer.
Es hat sich überraschenderweise ergeben, dass sich der in Figur 2 dargestell- te Angriff dadurch abwehren oder zumindest erschweren lässt, dass die in einer "White Box"-Implementierung, z.B. der in Figur 1 angedeuteten "White Box"-Implementierung 26b, eingesetzten Lookup-Tabellen statistisch geeignet permutiert werden. Unter einer geeigneten statistischen Permutation einer Lookup-Tabelle wird hier eine Permutation verstanden, bei der die ein- zelnen Bits der permutierten Lookup-Tabelle nicht mit den Bits der ursprünglichen Lookup-Tabelle korrelieren. Mit anderen Worten: unter einer geeigneten Permutation einer Lookup-Tabelle T wird hier eine Permutation P verstanden, bei der die einzelnen Bits der permutierten Lookup-Tabelle T'(x) = P(T(x)) bei zufällig variierendem Input x nicht mit den Bits T(x) korrelieren.
Figur 3 zeigt in Form eines Flussdiagramms eine bevorzugte Ausführungs- form eines Verfahrens zum Härten der "White Box"-Implementierung 26b von Figur 1.
In einem ersten Schritt S10 von Figur 3 wird eine Lookup-Tabelle in der "White Box"-Implementierung 26b ausfindig gemacht.
Diese Lookup-Tabelle wird, wie vorstehend beschrieben, in Schritt Sil von Figur 3 statistisch derart permutiert, dass die einzelnen Bits der permutierten Lookup-Tabelle im Wesentlichen nicht mit den Bits der ursprünglichen Lookup-Tabelle korrelieren, d.h. die Lookup-Tabelle T wird hier derart mit- tels einer Permutation P permutiert, dass die einzelnen Bits der permutierten Lookup-Tabelle T'(x) = P(T(x)) bei zufällig variierendem Input x nicht mit den Bits T(x) korrelieren.
Für Details zu statistischen Permutationen von Lookup-Tabellen von "White Box"-Implementierungen im Allgemeinen, d.h. Permutationen, bei denen nicht sichergestellt ist, dass die einzelnen Bits der permutierten Lookup- Tabelle im Wesentlichen nicht mit den Bits der ursprünglichen Lookup- Tabelle korrelieren, wird auf die Veröffentlichung " A Tutorial on White Box AES", James A.Muir, Cryptology ePrint Archive, Report 2013/104,
http:/ /eprint.iacr.org/2013/104 verwiesen.
Wie in Schritt S12 von Figur 3 dargestellt, kann der Schritt Sil von Figur 3 für weitere, vorzugsweise alle Lookup-Tabellen der "White Box"- Implementierung 26b durchgeführt werden. Nachdem wenigstens eine Lookup-Tabelle der "White Box"- Implementierung 26b erfindungsgemäß in Schritt Sil von Figur 3 "gehärtet" worden ist, können in einem Schritt S13 weitere Maßnahmen ergriffen werden, den in Figur 2 dargestellten Angriff abzuwehren oder zumindest zu erschweren. Allgemein lassen sich diese weiteren Maßnahmen gemäß bevorzugter Ausführungsformen der vorliegenden Erfindung als ein Einstreuen von Zufall in bzw. als ein "Randomisieren" der "White Box"- Implementierung 26b bezeichnen. Hierbei wird unter "Randomisieren" im Wesentlichen verstanden, dass bei jeder Ausführung der "White Box"- Implementierung 26b ein zusätzlicher, variierender Zufall, vorzugsweise in Form von Zufallszahlen, eingestreut wird.
Im Einzelnen können gemäß bevorzugter Ausführungsformen der Erfindung die folgenden weiteren Maßnahmen ergriffen werden:
1. Der Programmablauf der "White Box"-Implementierung 26b kann zufällig verwürfelt werden. Hierzu werden Abschnitte der "White Box"- Implementierung 26b, die parallelisiert werden können, in zufälliger Reihenfolge ausgeführt. Dabei wird die Reihenfolge für jeden Durchlauf, d.h. für jeden neuen Plaintext, neu zufällig erzeugt. Wie dies dem Fachmann bekannt ist, kann beispielsweise der S-Box-Lookup bei einer Implementierung des AES- Algorithmus parallelisiert werden.
2. In die "White Box"-Implementierung 26b können Code- Varianten einge- bracht werden, wobei die Code- Varianten trotz unterschiedlichem Programmablauf die gleiche Funktionalität bereitstellen. Bei der Ausführung der "White Box"-Implementierung kann dann zufällig eine dieser funktional äquivalenten Code-Varianten ausgewählt. 3. Die "White Box"-Implementierung 26b kann so modifiziert werden, dass Zwischenergebnisse, Eingabedaten und/ oder Ausgabedaten zufällig maskiert werden. Hierzu werden die Zwischenergebnisse, Eingabedaten und/ oder Ausgabedaten als Summe zerlegt, wobei jeder einzelne Summand zufällig ist. Ist beispielsweise x ein zu maskierendes Datenelement und r eine Zufallszahl, dann können statt des Datenelements x die Datenelemente "x XOR r" und r verarbeitet werden, wobei die für das Datenelement x ausgelegten Operationen entsprechend an die Arbeit mit den Datenelementen "x XOR r" und r angepasst werden müssen. Allgemeiner kann das Datenele- ment x als Summe (arithmetisch oder XOR) von mehreren Datenelementen xi, i=l,...,n dargestellt werden. Von den vielen möglichen Darstellungen wird eine zufällig ausgewählt. Die anfangs genannte Darstellung ergibt sich für n=2 mit xl = x XOR r und x2 = r. 4. Insbesondere im Zusammenhang mit asymmetrischen Kryptoalgorithmen können in die "White Box"-Implementierung 26b zufällige Veränderungen eingebracht werden, die bei den in der Implementierung 26b vorgenommenen Berechnungen wieder herausfallen. Vorzugsweise können hierzu die dem Fachmann bekannten Blinding-Techniken verwendet werden, wie diese beispielsweise in Abschnitt 3.4.1.1 des Dokuments "BSI: Minimum Require- ments for Evaluating Side-Channel Attack Resistance of RSA, DSA and Dif- fie-Hellman Key Exchange Implementations", Part of AIS46,
https : / / www.bs.bund. de / SharedDocs / Downloads / DE / BSI / Zertifizierung /Interpretationen /AIS 46 BSI guidelines SCA RSA VI 0 e pdf .pdf be- schrieben werden.
5. In die "White Box"-Implementierung 26b können tabellierte Funktionen randomisiert werden. Bei kryptographischen Algorithmen, die auf einem Prozessor ablaufen, sind Funktionen häufig in Form von Tabellen auf einem Speicher hinterlegt, beispielsweise die S-Boxen beim AES- oder DES- Algorithmus. Ist beispielsweise T eine Funktion, die in der "White Box"- Implementierung 26b in Form der Werte T(0), T(l), T(2), ... hinterlegt ist, kann die "White Box"-Implementierung 26b dadurch gehärtet werden, dass stattdessen beispielsweise die Werte T'(k) = u XOR T(k XOR v) hinterlegt werden, wobei die Zufallszahlen u und v bei jedem Durchlauf der gehärteten "White Box "-Implementierung 26b neu gewählt werden.
6. In der "White Box"-Implementierung 26b verwendete Lookup-Tabellen können jeweils durch mehrere funktional äquivalente Varianten von
Lookup-Tabellen ersetzt werden. Dabei sind diese Varianten von Lookup- Tabellen vorzugsweise gemäß dem in Figur 3 dargestellten und vorstehend beschriebenen Schritt Sil gehärtet, d.h. statistisch derart permutiert, dass die einzelnen Bits der permutierten Lookup-Tabelle im Wesentlichen nicht mit den Bits der ursprünglichen Lookup-Tabelle korrelieren. Bei der Durchführung der "White Box"-Implementierung kann jeweils eine der funktional äquivalenten Varianten von Lookup-Tabellen zufällig ausgewählt werden.
Obgleich es bevorzugt ist, dass die vorstehend beschriebenen Maßnahmen 1 bis 6 zum "Randomisieren" der "White Box"-Implementierung 26b in Verbindung mit dem in Figur 3 dargestellten und vorstehend beschriebenen statistischen Permutieren von Lookup-Tabellen der " White Box"- Implementierung 26b eingesetzt werden, wird der Fachmann erkennen, dass diese Maßnahmen prinzipiell auch eigenständig dazu eingesetzt werden können, den in Figur 2 dargestellten Angriff auf die "White Box"- Implementierung abzuwehren oder zumindest zu erschweren. Bezugszeichenliste :
10 Kommunikationssystem
20 Mobiles Endgerät
22 Chip
24 Prozessor
26 Speichereinheit
26a Softwareapplikation
26b "White Box"-Implementierung eines Kryptoalgorithmi
30 Rechenwerk
32 ALU
34, 36, 38 Register R0, Rl und R2
40 Steuerwerk
42 Programmzähler PC
44 Befehlsregister IR
46 Statusregister SR
48 Stapelregister bzw. Stapelzeiger (Stack-Pointer) SP
50 Kommunikationskanal
60 Server bzw. Terminal

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Testen einer auf einem Prozessor (24) ausführbaren "White Box"-Implementierung (26b) eines kryptographischen Algorithmus, die mittels eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugt und auf dem Prozessor (24) in Form von Maschinenbefehlen vorliegt, wobei der Prozessor (24) wenigstens ein Register (R0, R , R2) umfasst und das Verfahren die folgenden Schritte umfasst:
(a) das Einspeisen eines Plaintexts einer Vielzahl von Plaintexten in die " White Box "-Implementierung (26b);
(b) das schrittweise Auslesen und Abspeichern des Inhalts des wenigstens einen Registers (R0, Rl, R2) des Prozessors (24) beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"-Implementierung (26b), wobei beim schrittweise Abarbeiten der Maschinenbefehle der "White Box"- Implementierung (26b) zur Erzeugung des Ciphertextes aus dem Plaintext Zwischenergebnisse erzeugt werden können;
(c) das N-malige Wiederholen der vorstehenden Schritte (a) und (b) mit einem weiteren Plaintext der Vielzahl von Plaintexten; und
(d) das statistische Auswerten der Inhalte der Register (R0, Rl, R2) und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte, indem nach Korrelationen zwischen den Inhalten der Register (R0, Rl, R2) und den Plaintexten, den Zwischenergebnissen und/ oder den aus den Plaintexten erzeugten Ciphertexten gesucht wird, um den geheimen Schlüssel zu ermitteln.
2. Verfahren nach Anspruch 1, wobei
- der Inhalt eines Registers für einen Plaintext als Funktion der Anzahl der abgearbeiteten Maschinenbefehle analog zu einer Stromkurve bei der differentiellen Stromanalyse behandelt wird; oder / und
- der Schritt (d) des statistischen Auswertens der Inhalte der Register (R0, Rl, R2) und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte den Schritt des Auswertens mittels statistischer Verfahren umfasst, die aus der differentiellen Stromanalyse bekannt sind.
3. Verfahren nach Anspruch 1, wobei die "White Box"-Implementierung (26b) Teil einer Softwareapplikation (26a) zum Durchführen einer digitalen Transaktion ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, wobei N derart groß gewählt ist, dass ein statisches Auswerten der Inhalte der Register (R0, Rl, R2) und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintexten erzeugten Ciphertexte möglich ist.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Schritte (a) und (b) mit wenigstens 10, 100 oder 1000 unterschiedlichen Plaintexten durchgeführt werden.
6. Verfahren nach Anspruch 1, wobei beim Schritt (b) das Auslesen des Inhalts des wenigstens einen Registers erst ab einem in der "White Box"- Implementierung (26b) vordefinierten Maschinenbefehl durchgeführt wird und vorzugsweise weiter beim Schritt (b) das Auslesen des Inhalts des wenigstens einen Registers ab dem vordefinierten Maschinenbefehl für eine vordefinierte Anzahl M von Maschinenbefehlen durchgeführt wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei der "White Box"-Implementierung (26b) eines kryptographischen Algorithmus um eine "White Box"-Implementierung des AES- Algorithmus handelt.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei beim Schritt (d) des statistischen Auswertens der Inhalte der Register (R0, Rl, R2) und der Plaintexte, der Zwischenergebnisse und/ oder der aus den Plaintex- ten erzeugten Ciphertexte solche Zwischenergebnisse und/ oder aus den Plaintexten erzeugte Ciphertexte zur statistischen Analyse verwendet werden, die von nur möglichst wenigen Bits des geheimen Schlüssels abhängen.
9. Verfahren zum Härten einer auf einem Prozessor (24) ausführbaren "White Box"-Implementierung (26b) eines kryptographischen Algorithmus, die unter Verwendung eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugen kann, wobei die "White Box"-Implementierung (26b) derart ausgestaltet ist, dass bei der Erzeugung des Ciphertextes wenigstens eine Lookup-Tabelle zum Einsatz kommt, um statisch Eingabewerte der Lookup-Tabelle auf Ausgabewerte der Lookup-Tabelle abzubilden, wobei das Verfahren den Schritt umfasst, dass die Lookup-Tabelle derart statistisch permutiert wird, dass die einzelnen Bits der permutierten Lookup-Tabelle im Wesentlichen nicht mit den Bits der Lookup-Tabelle korrelieren.
10. Verfahren nach Anspruch 9, wobei das Verfahren ferner den Schritt des Randomisierens der "White Box"-Implementierung (26b) umfasst.
11. Verfahren zum Härten einer auf einem Prozessor (24) ausführbaren "White Box"-Implementierung (26b) eines kryptographischen Algorithmus, die unter Verwendung eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugen kann, wobei die "White Box"-Implementierung (26b) derart ausgestaltet ist, dass bei der Erzeugung des Ciphertextes wenigstens eine Lookup-Tabelle zum Einsatz kommt, um statisch Eingabewerte der Lookup-Tabelle auf Ausgabewerte der Lookup-Tabelle abzubilden, wobei das Verfahren den Schritt des Randomisierens der "White Box"- Implementierung (26b) umfasst.
12. Verfahren nach Anspruch 10 oder 11, wobei der Schritt des Randomisierens der "White Box"-Implementierung (26b) einen oder mehrere der fol- gende Schritte umfasst:
- den Schritt des zufälligen Verwürfeins des Programmablaufs der "White Box"-Implementierung (26b);
- den Schritt des Einbringens von funktional äquivalenten Code- Varianten, aus denen bei der Ausführung der "White Box"-Implementierung (26b) zu- fällig eine der Code- Varianten ausgewählt werden kann;
- den Schritt des zufälligen Maskierens von Zwischenergebnissen, Eingabedaten und/ oder Ausgabedaten;
- den Schritt des Einbringens von zufälligen Veränderungen, die bei den in der "White Box"-Implementierung (26b) vorgenommenen Operationen wie- der herausfallen;
- den Schritt des Randomisierens von tabellierten Funktionen;
13. Verfahren nach Anspruch 10 oder 11, wobei der Schritt des Randomisierens der "White Box"-Implementierung (26b) den folgenden Schritte umfasst: - den Schritt des Ersetzens von in der "White Box"-Implementierung (26b) verwendeten Lookup-Tabellen durch mehrere funktional äquivalente Varianten von Lookup-Tabellen, wobei bei der Durchführung der "White Box"- Implementierung (26b) jeweils eine der funktional äquivalenten Varianten von Lookup-Tabellen zufällig ausgewählt werden kann.
14. Verfahren nach Anspruch 13, wobei die Varianten von Lookup- Tabellen statistisch derart permutiert werden, dass die einzelnen Bits der permutierten Lookup-Tabelle im Wesentlichen nicht mit den Bits der ur- sprünglichen Lookup-Tabelle korrelieren.
15. "White Box"-Implementierung (26b) eines kryptographischen Algorithmus, die unter Verwendung eines geheimen Schlüssels aus einem Plaintext einen Ciphertext erzeugen kann, wobei die "White Box"- Implementierung (26b) mit einem Verfahren nach einem der Ansprüche 11 bis 14 gehärtet worden ist.
EP15801327.6A 2014-11-10 2015-11-09 Verfahren zum testen und zum härten von softwareapplikationen Ceased EP3218894A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP20020079.8A EP3686871A1 (de) 2014-11-10 2015-11-09 Verfahren zum härten von softwareapplikationen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014016548.5A DE102014016548A1 (de) 2014-11-10 2014-11-10 Verfahren zum Testen und zum Härten von Softwareapplikationen
PCT/EP2015/002246 WO2016074782A1 (de) 2014-11-10 2015-11-09 Verfahren zum testen und zum härten von softwareapplikationen

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP20020079.8A Division EP3686871A1 (de) 2014-11-10 2015-11-09 Verfahren zum härten von softwareapplikationen

Publications (1)

Publication Number Publication Date
EP3218894A1 true EP3218894A1 (de) 2017-09-20

Family

ID=54541013

Family Applications (5)

Application Number Title Priority Date Filing Date
EP15795111.2A Active EP3219043B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung 1
EP15795110.4A Active EP3219042B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung 2
EP15794079.2A Not-in-force EP3218893B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung
EP20020079.8A Pending EP3686871A1 (de) 2014-11-10 2015-11-09 Verfahren zum härten von softwareapplikationen
EP15801327.6A Ceased EP3218894A1 (de) 2014-11-10 2015-11-09 Verfahren zum testen und zum härten von softwareapplikationen

Family Applications Before (4)

Application Number Title Priority Date Filing Date
EP15795111.2A Active EP3219043B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung 1
EP15795110.4A Active EP3219042B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung 2
EP15794079.2A Not-in-force EP3218893B1 (de) 2014-11-10 2015-10-30 Gehärtete white box implementierung
EP20020079.8A Pending EP3686871A1 (de) 2014-11-10 2015-11-09 Verfahren zum härten von softwareapplikationen

Country Status (6)

Country Link
US (4) US10438513B2 (de)
EP (5) EP3219043B1 (de)
CN (2) CN107005404B (de)
CA (1) CA2966417C (de)
DE (1) DE102014016548A1 (de)
WO (4) WO2016074774A1 (de)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014016548A1 (de) 2014-11-10 2016-05-12 Giesecke & Devrient Gmbh Verfahren zum Testen und zum Härten von Softwareapplikationen
DE102015014038A1 (de) 2015-10-30 2017-05-04 Giesecke & Devrient Gmbh Alternative Darstellung des Krypto-Algorithmus DES
DE102015015953B3 (de) 2015-12-08 2017-04-27 Giesecke & Devrient Gmbh Kryptoalgorithmus mit schlüsselabhängigem maskiertem Rechenschritt (SBOX-Aufruf)
US10171234B2 (en) * 2015-12-16 2019-01-01 Nxp B.V. Wide encoding of intermediate values within a white-box implementation
DE102016008456B4 (de) * 2016-07-12 2018-03-29 Giesecke+Devrient Mobile Security Gmbh White Box AES Implementierung
US11689352B2 (en) * 2016-12-12 2023-06-27 Arris Enterprises Llc Strong white-box cryptography
CN106712965B (zh) * 2017-01-17 2020-02-18 数安时代科技股份有限公司 数字签名方法、装置以及密码设备
US10547449B2 (en) * 2017-05-30 2020-01-28 Nxp B.V. Protection against relay attacks in a white-box implementation
EP3651142A4 (de) * 2017-08-10 2021-03-24 Sony Corporation Verschlüsselungsvorrichtung, verschlüsselungsverfahren, entschlüsselungsvorrichtung und entschlüsselungsverfahren
US10630462B2 (en) * 2017-10-27 2020-04-21 Nxp B.V. Using white-box in a leakage-resilient primitive
EP3493457A1 (de) * 2017-11-30 2019-06-05 Gemalto Sa Verfahren zum schutz einer entropiequelle für gegenmassnahmen zur sicherung eines kryptografischen whitebox-algorithmus
CN108090349A (zh) * 2017-12-19 2018-05-29 武汉珈港科技有限公司 一种基于白盒指令和扩展图灵模型的应用程序白盒化保护系统及方法
US11700111B2 (en) * 2019-06-26 2023-07-11 Cryptography Research, Inc. Platform neutral data encryption standard (DES) cryptographic operation
CN111010266B (zh) * 2019-12-09 2023-04-07 广州市百果园信息技术有限公司 消息的加解密、读写方法、装置、计算机设备和存储介质
US11632231B2 (en) * 2020-03-05 2023-04-18 Novatek Microelectronics Corp. Substitute box, substitute method and apparatus thereof
CN112003687B (zh) * 2020-08-26 2023-04-07 成都卫士通信息产业股份有限公司 一种白盒运算方法、装置、电子设备及计算机存储介质
CN113541942B (zh) * 2021-07-12 2022-06-07 西安电子科技大学 基于arx白盒分组密码的数字内容加解密方法

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6075865A (en) * 1998-07-01 2000-06-13 Tecsec Incorporated Cryptographic communication process and apparatus
GB2345229B (en) * 1998-12-23 2003-12-03 Motorola Ltd Method for encrypting data
CA2327911A1 (en) 2000-12-08 2002-06-08 Cloakware Corporation Obscuring functions in computer software
FR2858496B1 (fr) * 2003-07-31 2005-09-30 Gemplus Card Int Procede pour la mise en oeuvre securisee d'un algorithme de cryptographie de type rsa et composant correspondant
WO2006118086A1 (ja) * 2005-04-28 2006-11-09 Matsushita Electric Industrial Co., Ltd. プログラム変換装置、暗号処理装置、暗号処理方法
FR2893796B1 (fr) * 2005-11-21 2008-01-04 Atmel Corp Procede de protection par chiffrement
FR2897216B1 (fr) * 2006-02-08 2008-05-02 Sagem Defense Securite Protection d'un algorithme cryptographique
ATE476803T1 (de) * 2006-03-07 2010-08-15 Research In Motion Ltd Tabellenteilung für kryptografische verfahren
WO2007105126A2 (en) * 2006-03-10 2007-09-20 Koninklijke Philips Electronics N.V. Method and system for obfuscating a cryptographic function
CN101491000B (zh) * 2006-07-12 2011-12-28 耶德托公司 用于混淆密码函数的方法和系统
BRPI0714242A2 (pt) * 2006-07-12 2013-01-29 Koninkl Philips Electronics Nv sistema e mÉtodo para aumentar a resistÊncia Á adulteraÇço de uma unidade de processamento de dados digitais, e, produto de programa de computador
US20100080395A1 (en) * 2006-11-17 2010-04-01 Koninklijke Philips Electronics N.V. Cryptographic method for a white-box implementation
WO2008119901A2 (fr) 2007-02-28 2008-10-09 France Telecom Procede de dechiffrement par un algorithme cryptographique de donnees chiffrees
CN101978647A (zh) * 2008-01-31 2011-02-16 耶德托公司 保护智能卡
EP2304552B1 (de) * 2008-05-23 2019-11-06 Irdeto B.V. System und verfahren zum erzeugen von white-box-implementierungen von softwareanwendungen
US9654280B2 (en) * 2009-03-10 2017-05-16 Irdeto B.V. White-box cryptographic system with input dependent encodings
US10102398B2 (en) * 2009-06-01 2018-10-16 Ab Initio Technology Llc Generating obfuscated data
US8625794B2 (en) * 2009-06-19 2014-01-07 Irdeto Corporate B.V. White-box cryptographic system with configurable key using intermediate data modification
EP2293487A1 (de) * 2009-09-08 2011-03-09 Thomson Licensing Verfahren zur Diversifikation der Runden eines Verschlüsselungalgorithmus
FR2951599B1 (fr) * 2009-10-20 2011-11-25 St Microelectronics Rousset Procede securise de calcul cryptographique et composant electronique correspondant
ES2573644T3 (es) * 2009-12-30 2016-06-09 Koninklijke Philips N.V. Procedimiento de generación de tabla de consulta para una caja blanca criptográfica
KR20120068543A (ko) * 2010-12-17 2012-06-27 한국전자통신연구원 화이트박스 암호를 이용한 소프트웨어 설치 장치 및 방법
US8605894B2 (en) 2011-07-14 2013-12-10 Apple Inc. Cryptographic process execution protecting an input value against attacks
EP2798771A4 (de) * 2011-12-29 2015-10-07 Intel Corp Verfahren und vorrichtung für einen nichtdeterministischen zufallsbitgenerator
CN104322002B (zh) * 2012-03-20 2018-03-30 爱迪德技术有限公司 更新秘钥信息
CN104335218B (zh) * 2012-03-30 2017-08-11 爱迪德技术有限公司 使用基函数编码来保护可访问的系统
US8976960B2 (en) * 2012-04-02 2015-03-10 Apple Inc. Methods and apparatus for correlation protected processing of cryptographic operations
US9584310B2 (en) * 2014-03-19 2017-02-28 Nxp B.V. Protecting a white-box implementation against attacks
CN104052595B (zh) * 2014-05-23 2017-02-08 戴葵 密码算法定制方法
US9569639B2 (en) * 2014-09-12 2017-02-14 Nxp B.V. Remapping constant points in a white-box implementation
DE102014016548A1 (de) 2014-11-10 2016-05-12 Giesecke & Devrient Gmbh Verfahren zum Testen und zum Härten von Softwareapplikationen
US9819486B2 (en) * 2014-12-19 2017-11-14 Nxp B.V. S-box in cryptographic implementation
US10235506B2 (en) * 2015-05-05 2019-03-19 Nxp B.V. White-box modular exponentiation
DE102015014038A1 (de) * 2015-10-30 2017-05-04 Giesecke & Devrient Gmbh Alternative Darstellung des Krypto-Algorithmus DES

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JAMES A MUIR: "A Tutorial on White-box AES", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20130228:053134, 28 February 2013 (2013-02-28), pages 1 - 25, XP061007352 *

Also Published As

Publication number Publication date
CA2966417A1 (en) 2016-05-19
US20170324542A1 (en) 2017-11-09
EP3219043A1 (de) 2017-09-20
CN107005404B (zh) 2020-11-03
US10431123B2 (en) 2019-10-01
WO2016074782A1 (de) 2016-05-19
CA2966417C (en) 2020-04-28
US10249220B2 (en) 2019-04-02
EP3218893B1 (de) 2019-01-30
CN107111966A (zh) 2017-08-29
CN107111966B (zh) 2020-12-29
EP3219042B1 (de) 2018-12-12
WO2016074774A1 (de) 2016-05-19
US10438513B2 (en) 2019-10-08
EP3219042A1 (de) 2017-09-20
US20170324547A1 (en) 2017-11-09
CN112002210A (zh) 2020-11-27
US20170352298A1 (en) 2017-12-07
DE102014016548A1 (de) 2016-05-12
EP3219043B1 (de) 2018-12-12
WO2016074776A1 (de) 2016-05-19
US20170324543A1 (en) 2017-11-09
EP3686871A1 (de) 2020-07-29
CN107005404A (zh) 2017-08-01
WO2016074775A1 (de) 2016-05-19
EP3218893A1 (de) 2017-09-20
US10403174B2 (en) 2019-09-03

Similar Documents

Publication Publication Date Title
WO2016074782A1 (de) Verfahren zum testen und zum härten von softwareapplikationen
EP2605445B1 (de) Verfahren und Vorrichtung zur Absicherung von Blockchiffren gegen Template-Attacken
EP2901611B1 (de) Seitenkanalgeschützte maskierung
EP3593483B1 (de) Übergang von einer booleschen maskierung zu einer arithmetischen maskierung
DE69911815T2 (de) Selbstkorrigierendes zufallsverschlüsselungssystem und -verfahren
WO2004070497A2 (de) Modulare exponentiation mit randomisierten exponenten
EP3387636B1 (de) Kryptoalgorithmus mit schlüsselabhängigem maskiertem rechenschritt (sbox-aufruf)
EP3369205B1 (de) Alternative darstellung des krypto-algorithmus des
DE102018006313A1 (de) Verfahren mit Safe-Error-Abwehrmaßnahme
DE102014216392A1 (de) Symmetrisches Iteriertes Blockchiffrierverfahren und entsprechende Vorrichtung
DE10303723B4 (de) Vorrichtung und Verfahren zum Berechnen von verschlüsselten Daten aus unverschlüsselten Daten oder von unverschlüsselten Daten aus verschlüsselten Daten
DE102004001659B4 (de) Vorrichtung und Verfahren zum Konvertieren einer ersten Nachricht in eine zweite Nachricht
DE10149191C2 (de) Verfahren und Vorrichtung zum Ermitteln von Ursprungsausgangsdaten aus Ursprungseingangsdaten auf der Basis einer kryptographischen Operation
EP2466782A1 (de) Verfahren zum geschützten Ausführen einer kryptographischen Berechnung
DE102018107114A1 (de) Seitenkanalgehärtete Operation
DE102012003968A1 (de) Gegen Ausspähen geschützte Berechnung
EP1760929A1 (de) Geschütztes kryptographisches Verfahren

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20170612

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20180815

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20200727