WO2008034900A1 - Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source - Google Patents

Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source Download PDF

Info

Publication number
WO2008034900A1
WO2008034900A1 PCT/EP2007/060056 EP2007060056W WO2008034900A1 WO 2008034900 A1 WO2008034900 A1 WO 2008034900A1 EP 2007060056 W EP2007060056 W EP 2007060056W WO 2008034900 A1 WO2008034900 A1 WO 2008034900A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
value
key
embedded
executable program
Prior art date
Application number
PCT/EP2007/060056
Other languages
English (en)
Inventor
Hans Martin Boesgaard Sørensen
Original Assignee
Boesgaard Soerensen Hans Marti
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 Boesgaard Soerensen Hans Marti filed Critical Boesgaard Soerensen Hans Marti
Priority to EP07803589A priority Critical patent/EP2064648A1/fr
Priority to US12/311,181 priority patent/US20090249492A1/en
Priority to PCT/EP2007/063983 priority patent/WO2008071795A2/fr
Priority to EP07857617A priority patent/EP2122530A2/fr
Priority to US12/448,249 priority patent/US8468351B2/en
Publication of WO2008034900A1 publication Critical patent/WO2008034900A1/fr
Priority to US13/889,764 priority patent/US8949607B2/en

Links

Classifications

    • 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/16—Program or content traceability, e.g. by watermarking
    • 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/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • 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
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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/60—Digital content management, e.g. content distribution

Definitions

  • the present invention is generally concerned with securing computer programs, network communication, and stored data against attacks.
  • the present invention can prevent most man-in-the-middle, phishing, and malware attacks on for example online banking applications, online investment applications, and online entertainment applications.
  • Argument An input, e.g. to a function, a server, or a HTTP request
  • Asymmetric key A cryptographic key to be used in an asymmetric algorithm.
  • Asymmetric algorithm An algorithm using one key for encryption and another key for decryption or an algorithm using one key for signing and another key for verifying the signature, Can for example be RSA or ECC.
  • Authentication tag See tag.
  • Block cipher An encryption/decryption algorithm operating on plaintext / ciphertext blocks of fixed length. Can for example be AES or 3DES. Also see [Sc96] pp.
  • Cipher See encryption / decryption algorithm. Ciphertext: An encrypted string.
  • Client application A computer program that can connect to a server application.
  • An application being a client towards a server might also be a server towards another client.
  • composition in this text, the composition of a function or algorithm that is different for each copy denotes the functionality of the specific function or algorithm in a specific copy.
  • Computer-executable program file For example an .exe, .dll, .ocx, .class, or .jar file.
  • Copy Two different copies of a computer program have the same overall features but may have different internal functions, e.g. key generators.
  • Cryptographic algorithm / function In this text, this denotes a mathematical function (or its implementation) that is used for communication or storage in the presence of an adversary. Examples include encryption / decryption algorithms, message authentication codes (MAC), or hash functions. Digital document: Includes HTML, XHTML, XML, PDF, word process files, and spread sheet files. Encryption / decryption algorithm: An encryption algorithm encodes data under a key such that it cannot be distinguished from random data. A decryption algorithm reverses the encryption algorithm and restores the original data, using a key. Can e.g. be a block cipher, a stream cipher or an asymmetric cipher.
  • Hash function A function that takes a string of any length as input and returns a string of fixed length as output. The function achieves a strong mixing of the string, and its output can be used as a short identifier for the input. Examples are collision resistant hash functions, one-way functions, or any family of pseudo-random functions). Also see [Sc96] pp.30-31. IV: Initialization vector. A publicly known string that is used to avoid that a cryptographic algorithm always produces the same output.
  • a message authentication code (or MAC) takes a key and a data string as input and produces an authentication tag as output. If the key is a secret shared by sender and receiver and if the tag is appended to the message, the receiver can re-run the MAC to verify that the data has not modified since it was written. Also see [Sc96] p.31.
  • Plaintext An un-encrypted string.
  • PRNG A pseudo-random number generator (or PRNG) takes a seed as input and generates an output string of arbitrary length. If the key is not known, the output string cannot be distinguished from random. Also see “pseudorandom sequence generator” in [Sc96] pp.44-45. Seed: Input to a PRNG.
  • Server application A computer program that can receive connections from a client application and/or provide services to a client application.
  • Server Software (i.e. server application), hardware, or combination thereof that can receive connections from a client application and/or provide services to a client application.
  • Source code For example the content of a .Java, .c, .cpp, .h, or .pas file.
  • Stream cipher An encryption/decryption algorithm operating on streams of plaintext or ciphertext. Also see [Sc96] pp.4, 189, and 197-199.
  • String A block of data. Can be a text string (a set of characters) or a binary string (a set of bits).
  • Symmetric key A cryptographic key to be used in a symmetric algorithm.
  • Symmetric algorithm An algorithm using the same key for both encryption and decryption or for both creating an authentication tag and verifying an authentication tag.
  • Tag Output of a MAC function.
  • Time stamp A string containing information about date and/or time of day. Version: Two different versions of a computer program have different features.
  • the invention provides a method of fabricating computer-executable program files from a source code, the method comprising the step of embedding, in each of the fabricated computer-executable program files, at least one value or means for generating at least one value, said value being uniquely selected or generated for each of the fabricated computer-executable program files, whereby all of the fabricated computer-executable program files are capable of carrying out instructions defined by the source code, and whereby each individual computer-executable program file is capable of generating a unique output, which depends on said uniquely selected or uniquely generated value.
  • the method of the first aspect of the present invention fabricates unique copies of a computer program (computer-executable program file), i.e. copies that are all capable of carrying out the same instructions to perform identical operations in terms of overall functionality.
  • the copies fabricated by the method of the first aspect of the invention all differ from each other in that each copy is capable of generating a unique output.
  • the at least one value may be embedded as a static value.
  • the at least one value may be generatable by the means for generating the value.
  • the means for generating the value may be generated at the stage of fabricating the computer-executable program files.
  • the means for generating the value are preferably adapted to generate the value at runtime of the computer-executable program files.
  • the unique output is normally generated at runtime of the computer-executable program files, but may also be embedded as a static value, which is generated at the fabrication stage.
  • the means for generating the at least one value may comprise computer program functionality, such as source code, e.g. in macro or script language, or compiled code capable of generating the value.
  • the unique output is preferably reproducible by another program or accessible by another program.
  • different copies of the computer-executable program files fabricated by the present method may be distributed to different users, such as users in a computer network, such as online banking users.
  • the other program capable of reproducing or accessing the unique output may, for example, be running on a server in the computer network, such as a server run by a bank.
  • the unique output may be used as a common secret or used to generate a common secret, such as one or more encryption keys.
  • the unique outputs of two copies of the computer program are uncorrelated, i.e. with the knowledge of one output, one cannot predict the unique output provided by another copy of the computer program.
  • the computer-executable program files fabricated may be capable of carrying out online banking transactions.
  • all copies of the program files will appear identical to users, i.e. all user interfaces are identical, and the programs carry out identical operations, except with regard to the unique output, which is different between different copies of the program files.
  • the operations carried out by all copies of the computer program may e.g. include prompting for user id and password, offering various functionalities, such as money transactions, account inquiries, etc.
  • the unique output produced by each individual copy of the program files is preferably not visible to or accessible by users.
  • Such embodiments include, in particular, most online banking applications, media players, anti virus programs, other security programs, financial programs, games, distributed computing applications, DRM applications.
  • the unique output may for certain applications be made visible to or accessible by users. For example, the output may be made available to users for debugging purposes.
  • the method according to the first aspect of the invention is preferably carried out on a device capable of automatically carrying out instructions as provided in a program.
  • the method is implemented on an electronic device including an electronic processor, such as a computer including a CPU.
  • each user or group of users preferably uses (is provided with) a different copy of the computer-executable program file. Whereas for certain applications it may be acceptable that the same copy is provided to two different users among many users, it is usually preferred that a copy provided to a user is not re-used, i.e. is not provided to another user.
  • the embedded means for generating the at least one value may depend on at least one embedded value.
  • the means for generating the at least one value may, for example, include a key generator for generating an encryption key, which is unique in respect of a particular copy of the program.
  • the key generated by the key generator may depend from a value, which is specific for one single copy of the program file, and which has been embedded at the fabrication stage.
  • key generators of different copies of the program use different arithmetic functions as well as different embedded values to enhance security.
  • the process of fabricating computer-executable program files from a source code may be divided into at least two steps.
  • a first step which is performed once, source code is converted into at least one intermediate file, such as a machine-code or object file.
  • the at least one intermediate file and optionally other files are converted into the computer-executable program file.
  • the second step is performed for each computer-executable program file.
  • At least a part of the source code used as input to the fabrication process may be evaluated to determine if it meets one or more predefined criteria for being equipped with the at least one embedded value or means for generating the at least one value. For example, at the step of fabricating, it may be determined if the computer-executable program file(s) to be used as input is intended to be capable of exposing confidential data. If this is the case, the fabrication software may be setup to deny fabrication.
  • the embedded means for generating the at least one unique value may comprise at least one extractor subfunction, as described in further detail below.
  • the extractor subfunction(s) may be uniquely selected for each computer-executable program file.
  • the unique output may be used to generate a cryptographic key, or used itself as a cryptographic key.
  • Such key may e.g. be used to generate an authentication tag for authenticating data or for authenticating the program itself or other programs, or for authenticating the execution environment, in which the program is run.
  • the execution environment to be authenticated may e.g. include an operating system, internet browser, or external software components.
  • the at least one embedded value or means for generating at least one value may be used as a serial number or to derive a serial number that can be used, e.g. by server software, to identify the copy of the computer program.
  • the server may include a database, from which the internal structure of the specific copy of the program can be derived, e.g. to reconstruct a key generator.
  • information about how a computer-executable program file is generated can be stored, such that the computer-executable program file can be reproduced or its functionality or part thereof can be reproduced or simulated, for example by a server.
  • the at least one embedded value or the means for generating the value may be constructed by an algorithm using a pseudo-random number generator (PRNG).
  • PRNG pseudo-random number generator
  • the embedded value or means for generating the value may be reproduced at a later stage, e.g. by a server.
  • the computer-executable program files may be obfuscated. More specifically, obfuscation renders it more difficult to extract, for example, a key generator from the fabricated program files, and patching of the fabricated program files is also rendered difficult.
  • the obfuscation method may depend random or pseudo-random data, so that its output varies in accordance with that data. Hence the obfuscation output may vary to further enhance security. Thus, if the obfuscation method is applied more than once to the same input (such as e.g. a source code or a compiled version of a program), the two obfuscated outputs will not be identical.
  • At least a part of the computer-executable program file may be stored in encrypted form and may be decrypted at runtime.
  • an unecrypted part of the program file may be used to initiate operation or setup of the program, e.g. to contact a server with a request for a decryption key for decrypting the remaining part(s) of the program file.
  • the decryption key provided by the server may be provided in encrypted form and may be decrypted by the program file, using a cryptographic key derived from the unique output.
  • the fabricated computer-executable program file including the at least one embedded value or embedded means for generating at least one value may contain program code that can read profile data, such as:
  • the program may include functionality allowing the profile data to be submitted to a server to allow the server to determine if the program is executed in an allowable environment.
  • data may be sent in encrypted or authenticated form between a first and a second program (programs C and D in Fig. 14).
  • the encryption/decryption key or authentication key may be derived from the at least one embedded value or means for generating the at least one value in the first program program C.
  • the encryption/decryption key or authentication key may be derived in the second program D from knowledge about the at least one embedded value or means for generating at least one value in the first program C.
  • data may be sent in encrypted or authenticated form between third and fourth programs, G and f/in Fig. 15.
  • the programs G and H both communicate securely with server / using cryptographic keys derived from G's and f/'s at least one embedded value or means for generating the at least one value.
  • the server / provides at least one cryptographic key to G and H to be used to encrypt/decrypt or authenticate at least a part of the data sent between G and H.
  • the present invention further provides a server from which computer-executable program files fabricated according to the fabrication method described above can be downloaded.
  • the invention provides a server communicating with a computer-executable program file fabricated according to the present fabrication method.
  • the invention further provides a document into which at least one computer-executable program file fabricated according to the present invention is embedded. Further, the invention provides a computer on which at least one computer-executable program file fabricated according to the present invention is stored or executed. Further, the invention provides a computer program for fabricating computer-executable program files from source code, the computer program comprising means for performing the fabrication method according to the present invention. Further, the invention provides a computer-readable data medium comprising such a computer program, and a computer loaded with the computer program. Further, the invention provides a computer-executable program file fabricated by the fabrication method of the present invention.
  • the present invention provides a computer program comprising a computer- executable program file fabricated from a source code, the computer program including, in said computer-executable program file, at least one embedded value or means for generating at least one value, said value being uniquely selected or uniquely generated for the computer-executable program file, whereby the computer-executable program file is capable of carrying out instructions provided by the source code and of generating a unique output, which depends from said uniquely selected or uniquely generated value.
  • the computer program may include functionality, i.e. program code, to carry out all method steps described above in connection with the fabrication method of the first aspect of the invention.
  • the present invention further provides a computer network comprising a server and a plurality of clients, wherein each client is loaded with a copy of a first computer program, and wherein the server is loaded with a second computer program, each copy of the first computer program comprising:
  • Each copy of the first computer program may include functionality, i.e. program code, to carry out all method steps described above in connection with the fabrication method of the first aspect of the invention.
  • the invention also provides a server for use in the above-described computer network, the server being suited for communication with said plurality of clients via the computer network, said second computer program being adapted to authenticate each copy of said first computer program based on said unique output.
  • the invention further provides a server communicating with a client computer program comprising a computer-executable program file fabricated from a source code, the computer program including, in said computer-executable program file, at least one embedded value or means for generating at least one value, said value being uniquely selected or uniquely generated for the computer-executable program file, whereby the computer-executable program file is capable of carrying out instructions provided by the source code and of generating a unique output, which depends from said uniquely selected or uniquely generated value.
  • the computer-executable program file may include functionality, i.e. program code, to carry out all method steps described above in connection with the fabrication method of the first aspect of the invention.
  • the server may include functionality that allows it to recreate at least one of
  • the server may further include functionality allowing it to load, from a database or file, at least one of
  • figure 1 shows an attack scenario.
  • we have the bank which is considered secure.
  • we have the Internet which connects the users' computers to the bank. From left, we have three legal users, who want to use the online banking application to conduct transactions. But at the right, we have an attacker who wants to make money by modifying other users' transactions or by fabricating transactions that to the bank look like transactions authorized by other users.
  • FIG 2 shows the components involved in onlinr banking.
  • the user and the bank are considered secure, but the online banking program, the computer, the data stored on the user's computer by the online banking program, and the Internet can be under control of an attacker. This can be used by the attacker to trick the user and/or the bank to modify or make transactions in the attackers favor.
  • Figure 3 shows how the present invention can improve the security of online banking.
  • a key generator in the online banking program (“netbank program” in the figure)
  • the online banking program's authenticity can be verified by the banking.
  • the online banking program will be secure.
  • a secure link can be established to the banking (illustrated by the green arrow between the online banking program and the bank), and finally, online banking data stored on the user's computer can be protected (illustrated by the green arrow between the online banking program and the online banking data ("netbank data” in the figure).
  • This solution leaves only one weakness: the link between the user and the online bank program (i.e. the user interface).
  • a key extractor is embedded into a computer- executable program file.
  • This key extractor may take an extractor IV as input and generates an extracted key as output (see left part of figure 4).
  • the extracted keys can for example be used as key in cryptographic functions.
  • computer-executable program files are generated in a way such that one or more unique strings are embedded into each copy.
  • These one or more unique strings can for example be used as parameters to a key extractor in order to generate keys that are unique for each copy, as serial numbers, or as keys in cryptographic functions.
  • the extractor function always returns a constant string.
  • the extracted key is a constant.
  • the extractor function is build as shown in figure 5: •
  • the function has a number of inner state words (their initial values are W 1 , W 2 , W 3 , and W 4 in the figure).
  • Each extractor subfunctions can take one or more inner state words as input and can change the value of one or more inner state words.
  • One or more of the initial values of the inner state words (W 1 , W 2 , W 3 , and W 4 in the figure) may be derived from an extractor IV.
  • One or more of the extractor subfunctions may depend on an extractor IV or value derived thereof.
  • One or more of the extractor subfunctions may depend on a constant value.
  • extractor subfunctions are chosen from a set of available extractor subfunctions when the computer-executable program file containing an extractor function is generated.
  • the set of available extractor subfunctions can be defined in the program generating the computer-executable program files containing an extractor function.
  • the function combining the inner state words into the extracted key (the L function in figure 5) can for example consist of one or more of:
  • a MAC function • An encryption function; e.g. one block cipher operation for each state words using the state word as key, forwarding the output (ciphertext) to the next as input (plaintext). The output of the last operation is the extracted key.
  • the extractor function is build as shown in figure 6:
  • a number of extractor subfunctions are manipulating the inner state words (F 1 , F 2 , ... F n in the figure).
  • Parameters for the extractor subfunctions are generated from the extractor IV by a function (illustrated by the K function in the figure).
  • Constants for the extractor subfunctions (C 1 , C 2 , ...C n in the figure) are embedded in the computer-executable program file.
  • Each extractor subfunction can take one or more inner state words as input and can change the value of one or more inner state words.
  • the extractor subfunctions produces a balanced output, are non-linear, and/or are correlation-resistant.
  • the extractor subfunctions relies on bijective function (e.g. addition, subtraction, xor, or rotating) or on table lookups (e.g. the s-boxes from the encryption algorithm AES).
  • bijective function e.g. addition, subtraction, xor, or rotating
  • table lookups e.g. the s-boxes from the encryption algorithm AES.
  • extractor functions have jump instructions. These jump instructions may for example be conditional.
  • the conditional jumps can for example depend on one or more of:
  • an extracted key or one or more unique strings are used as input to a blender function (see right part of figure 4).
  • This blender function also takes a blender IV as input and generates a purpose key as output.
  • the output from a key generator (an extracted key) is used as input to a blender function (see figure 4).
  • a unique key generator function is embedded into each computer-executable program file.
  • the extractor function is or is not different for each copy.
  • the blender function is or is not different for each copy.
  • a blender function relies on cryptographic functions to generate the purpose key from its inputs.
  • a blender function concatenates the blender IV and the extracted key and processes the resulting string (or a string derived thereof) by a hash function.
  • the output from the hash function or a string derived thereof is used as purpose key.
  • a blender function uses the blender IV (or a string derived thereof) as message and the extracted key (or a string derived thereof) as key to a MAC function.
  • the output of the MAC function (or a string derived thereof) is used as purpose key.
  • a blender function uses the blender IV (or a string derived thereof) as plaintext and the extracted key (or a string derived thereof) as key to a block cipher.
  • the output of the block cipher (or a string derived thereof) is used as purpose key.
  • a blender function uses the blender IV (or a string derived thereof) as key and the extracted key (or a string derived thereof) as plaintext to a block cipher.
  • the output of the block cipher (or a string derived thereof) is used as purpose key.
  • the key generator consists of a constant string that directly or after manipulation is used as key for a block cipher.
  • the generator IV (or a string derived thereof) is used as plaintext and the cipher text output (or a string derived from it) is used purpose key.
  • the key generator consists of a constant string that is concatenated with the generator IV or by other means combined with the generator IV.
  • the resulting string is hashed and the resulting string (or something derived from it) is used as purpose key.
  • an extractor IV and/or a blender IV are derived from a key generator IV.
  • a key generator IV is derived from a counter value.
  • a key generator IV is derived from a time stamp.
  • several purpose keys are generated from one key generator IV. This can be achieved in several ways, for example: • By manipulating the key generator IV before calling the key generator.
  • a purpose key is used as at least one of:
  • An authentication value i.e. a value that can be used to confirm that a computer- executable program file contains a given key generator.
  • data from the user, data about the user, or data from something in the user's possession is included in the key generation process.
  • user authentication can be embedded into the key generation.
  • Data from the user can for example be a password, an account number, or a user name.
  • Data about the user can for example be biometric data.
  • Data from something in the user's possession can for example be a one-time password or a short-time password (e.g. from a password generator device) or a key stored in a file on a devices (e.g. a hard disk or a USB memory stick).
  • a computer-executable program file has several key generators.
  • one computer program has a key generator embedded into its program code.
  • Another computer program has knowledge about the composition of the key generator and can, based on this knowledge, reproduce the key generator's functionality and thus its output.
  • the process of generating a computer- executable program file with a key generator comprises generating a random or unique seed string.
  • This seed string is expanded to a longer string using a PRNG.
  • This string (or something derived from it) is divided into substrings used for constructing the extractor function. These substrings can for example choose which extractor subfunctions to use, on which inner state words they operate, or be used as constants given to the subfunctions (e.g. C 1 , C 2 , ...C n in figure 6). If all non-static information needed to construct an extractor function is derived from the expanded string (and thus from the seed string), knowledge of the seed string is enough to reproduce the complete key generator.
  • serial numbers can for example be used to look up the copy's PRNG seed in a table or a database. If a party knows the PRNG seeds used to generate a program with a given serial number, that party can reproduce the key generator and thus produce the same keys as the computer-executable program file.
  • the serial numbers can for example be consecutive, random, or encrypted consecutive numbers.
  • a computer-executable program file with a key generator is embedded or included in another file, for example a Java archive file (.jar file), an archive file (e.g. a .tar file), a compressed file (e.g. a .gz file), a compressed archive file (e.g. a .zip file), or an install file.
  • a Java archive file e.g. a .tar file
  • a compressed file e.g. a .gz file
  • a compressed archive file e.g. a .zip file
  • a client program has a key generator embedded into its program code and a server has knowledge about the composition of the key generator.
  • the client program and the server program can generate the same purpose key given the same key generator IV.
  • client programs with embedded key generators are communicating with one or more server programs.
  • Figure 7 shows an example.
  • the client program generator is a program that can generate client programs with unique embedded key generators. For each client program it has generated, it stores the generated program in a program file database and the program's serial number and PRNG seed in a seed database.
  • the client program can for example be distributed to users via a web server or on optical media via retail stores or by mail.
  • the client program can communicate with a transaction server using purpose keys generated by the key generator if the transaction server has access to the seed database, since it using the program's serial number (sent from the client program to the server) can find the client program's seed in the seed database and using the seed can reproduce the client program's key generator.
  • client programs with embedded key generators are communicating with one or more server programs.
  • the client program generator stores the generated client programs in a program file database and stores the program's serial number with a program containing only the key generator as embedded in the generated client program in a key generator database.
  • the client program can communicate with a transaction server using keys generated by the key generator if the transaction server has access to the key generator database, since the key generator program can generate the same keys as the client program's key generator.
  • client programs with embedded key generators are communicating with one or more server programs.
  • the client program generator generates client programs with unique key generators on-demand when a user requests a program.
  • the serial number and PRNG seed is stored in a seed database.
  • serial number and key generator is stored in a key generator database.
  • the generated computer-executable program file or a part thereof is obfuscated.
  • This obfuscation may make it harder to derive information on how the key generator function is build and/or to make it harder to reverse-engineer the program in general.
  • the obfuscation may make it harder to produce a computer program that can automatically patch (i.e. modify) the computer-executable program file.
  • the obfuscation process can for example comprise one or more of the following techniques:
  • byte code e.g. Java code
  • source code files e.g..Java files
  • output files e.g..class files
  • the output files contain information about the program code's interface etc.
  • a group of output files is often combined in an archive file (e.g. a .jar file).
  • archive file e.g. a .jar file
  • These output files are linked together at runtime.
  • the problem is that all this structure of the compiled code makes the code easier to analyze and reverse-engineer.
  • This structure can, however, be removed by restructuring the code in a way such that functionality from a number of output files is combined into one output file. This may require that the program code can handle some tasks that are normally handled by the system, e.g. assigning and freeing memory, handling stack, and handling error situations.
  • byte code representing more than one class or more than one function is combined into byte code representing one class or one function.
  • Figure 13 illustrates an example.
  • the function A contains program code (the lines with aa, bb, cc, and dd).
  • A also contains a call to the function B and a return statement that returns from the function A.
  • the function B also contains program code (the lines with ee, ff, gg, and hh), a call to the function C, and a return statement.
  • the function C contains program code (the line with ii) and a return statement.
  • the functions A and B are combined.
  • the combined function is called A and still has all the functionality of the original function A but has the functionality of the function B embedded into it.
  • the beginning of the new function A is similar to the original function A except that the call to B is now a local jsr (lump to subioutine)
  • the code from the original function B is inserted hereafter, but before the original B code, functionality to allocate temporary memory to be used by the functionality of B is added (in the original code this was handled automatically by the runtime environment or operating system as B was a separate function).
  • functionality to free temporary memory is added in the end of the original B code.
  • the "return from function" statement is replaced by a local ret (return from subroutine) statement.
  • the call to C is unchanged. Also the function C itself is unchanged.
  • obfuscation methods are used that confuse debugging tools or disassembler / decompiler tools, e.g. adding program code between functions that is never called but confuses a disassember to decode the code with wrong alignment or use of software interrupts.
  • destination addresses for jump instructions and/or parameters to instructions are read from a table.
  • the table or part thereof might be provided in the computer-executable program file, eventually in encrypted form to be decrypted at runtime.
  • the decryption key used to decrypt the encrypted table entries might be generated by a key generator, read from a file or downloaded from a server.
  • the table or part thereof might be downloaded or updated with records downloaded from a server.
  • a table as described above is given to a client application to allow it to be executed as part of an anti-piracy scheme.
  • This table can for example be given when the user has registered his copy and/or typed in his copy's serial number.
  • This table can for example be stored on disk in encrypted form when is has been received by the client application.
  • a source code file or an intermediate file derived from a source code file is evaluated before being processed in order to determine if it meets certain criteria before the source code converted into a computer-executed program file and is equipped with a key generator.
  • criteria might be defined by the same organization as developed the source code. A description of these criteria might be distributed along with the computer-executable program file.
  • the criteria used to evaluate a source code file or intermediate file are defines such that the evaluated program cannot export data, access data, create data, or manipulate data in a way not wanted by the entity defining the criteria.
  • a criteria file can be a manifest file as e.g. used in Java.
  • a criteria file associated to a computer- executable program file is evaluated before the computer program is executed to determine if the criteria meets the policies defined for the computer or environment it is about to be executed on.
  • a computer program collects data that can be used to identify the computer it runs on (also called hardware profile data).
  • This data can for example be any of:
  • a server application collects data about the computer a client application runs on without involving the client application.
  • This data can for example be any of: • I P number.
  • a server application uses hardware profile data (collected by client program and/or server program) to detect if a client program runs on the correct computer.
  • hardware profile data collected by a client application is combined in groups of strings. These strings are hashed, and the resulting strings are sent to the server. This can anonymize the user's data but still allow the server application to detect changes in the hardware profile.
  • a string unique for the given user or client application can for example be added to the hardware profile data strings before hashing. This will ensure that even if two users have the same hardware components, the server cannot detect it as the hash strings will be different.
  • the generated computer-executable program file can be authenticated to detect if it is authentic.
  • This authentication can for example be performed by the program itself, by another program, or by a hardware device.
  • This authentication can for example be based on a purpose key generated by a key generator.
  • Figure 8 shows a method for authenticating a computer-executable program file.
  • a purpose key is generated by the key generator (KG in the figure) from a key generator IV.
  • the program file may be pre-processed by a function (F in the figure).
  • the program file or the pre-processed program file is then processed by a MAC function taking the generated purpose key as its key.
  • the output of the MAC function is the authentication tag used to authenticate the program.
  • the pre-processor might be individual for each program copy.
  • a method for authenticating the computer- executable program file is to process the file, a part thereof, or something derived thereof by a hash function to obtain a hash value representing the content of the file.
  • Another method is to process several parts of the computer-executable program file or something derived thereof to obtain several hash values as illustrated in figure 9. These parts may overlap and parts may be left out. This processing might be individual for each copy of the computer- executable program file.
  • hash functions other cryptographic functions, e.g. MAC functions can be used to obtain a value with similar properties as a hash value.
  • the one or more hash values can for example be processed by a MAC function where the MAC function is given a purpose key from a key generator (KG in the figure) as key.
  • the authenticity of a computer-executable program file can be verified by calculating the expected MAC value and compare it with the MAC value generated by the program. If these are equal, the computer-executable program file is considered authentic.
  • a server might generate a random key generator IV value and send it to a client program. The client program then generates the MAC value over its own computer-executable program file using the key generator IV as input to the key generator. The generated MAC value is returned to the server.
  • the server already knows the hash value(s), generates the MAC key, and calculates the MAC value. If the server's calculated MAC value is equal to the MAC value received from the client, the client is considered authentic.
  • a part of the computer-executable program file is not authenticated. This can for example allow for patching and updating without changing data on the server.
  • a part of a computer-executable program file is updated.
  • the hash value(s) on the server for the parts of the file that is updated are updated to allow the server to verify the authenticity of the new computer-executable program file.
  • a computer-executable program consists of several files. All or some of these files are included in the authentication process.
  • a computer-executable program file authenticates itself towards another computer-executable program file. This allows for example sub-modules to authenticate themselves towards a main module.
  • a computer-executable program file is authenticated towards on or more of:
  • a security-related hardware component e.g. a Trusted Platform Module (TPM), a smartcard, or a smartcard reader.
  • TPM Trusted Platform Module
  • An input-output device e.g. a graphics adaptor, a screen, a keyboard, a keyboard adaptor, a mouse, a mouse adaptor, a sound card, a speaker, or a microphone.
  • a communication device e.g. a network adaptor, a modem , a switch, a router, or a firewall
  • a network e.g. towards a switch, a router, or a firewall.
  • a storage device e.g. a hard drive, a storage adaptor, a raid adaptor, a storage-area network (SAN), or a network-attached storage (NAS) • Another kind of hardware module.
  • a program running on another hardware device e.g. another computer or a server.
  • the generated authentication tag is used as a key.
  • Different keys can for example be generated by appending different strings to the input to the MAC function.
  • an execution environment in which a computer- executable program file is executed is authenticated.
  • This authentication can for example be performed by hashing some or all of the program code, computer-executable program files, and data files of the execution environment.
  • the generated hash value can for example be compared with a list of known hash values of authentic or accepted execution environments stored in the program calculating the hash value or sent to a server that can compare it with a list of authentic or accepted hash values.
  • a purpose key generated by a key generator is used to encrypt data to be transmitted or to decrypt data that has been transmitted.
  • a purpose key generated by a key generator is used to generate an authentication tag on data to be transmitted or data that has been transmitted.
  • This tag can for example be transmitted along with the data.
  • the transmitted tag can for example be compared with the tag generated by the receiver to verify if the transmitted data is authentic.
  • a secure communication link is established between a server application and a client application by using the shared knowledge of the client's key generator.
  • the server generates one or more random key generator IVs and sends them to the client application. • Using the key generator IVs, one or more keys are generated by both the client application and the server application.
  • a program authenticity check is built into setting up the link encryption/authentication keys.
  • the key generator IV generated by the server is used to generate an authentication tag authenticating the computer-executable program file.
  • This tag can for example be used as key or one or more keys can be derived from the tag.
  • Keys can be derived for example by appending a string to the authentication tag and hashing it. This hash value is then used e.g. as encryption key. Append another string to the tag and hash it. This second hash value is used e.g. as authentication key. See figure 10.
  • Another example is to use the authentication tag as key and encrypt one string using an encryption algorithm to obtain an encryption key and to encrypt another string to obtain an authentication key.
  • the key generator IV is generated from a string generated by the server application and a string generated by the client application. These two strings can for example be combined by means of a hash function.
  • Two key generator IVs may be generated and used instead of one to generate the two keys.
  • request and response messages are protected.
  • the request payload string is encrypted and authenticated using the keys.
  • the responding party generates keys using the key generator IV.
  • the protected request string is verified and decrypted by the responding party.
  • the protected response payload is verified and decrypted by the requesting party.
  • the requesting party and the responding party may use different IVs for encryption and authentication or use different keys, e.g. using a derived key generator IV for generating keys for protecting the response payload or using different generator IVs each way.
  • the derived key generator IV may consist of the original key generator IV combined with a key generator IV chosen by the responding party.
  • the responding party's key generator IV may be unique for each message and may be sent with the message to the requesting party.
  • the combination can for example be achieved by XOR'ing the key generator IVs, by concatenating them and hashing the result, or by a block cipher by using the requesting party's key generator IV as plaintext and the responding party's key generator IV as key.
  • communication link sessions are protected.
  • the communication link may be used to transmit data synchronous or asynchronous.
  • the client application connects to the server application.
  • the server application generates a key generator IV and sends it to the client application.
  • the generator IV can for example be a combination of a string generated by the server and a string generated by the client.
  • An example of an application using asynchronous transmission is AJAX (Asynchronous JAva XML).
  • the server application and the client application are communicating by means of at least one of:
  • a web browser e.g. using HTTP or HTTPS
  • o Cookies • A web browser (e.g. using HTTP or HTTPS), for example via o Cookies.
  • o Data embedded into HTML, XHTML, or XML o Data returned by GET or POST commands, o HTTP headers.
  • SMS e.g. on GSM phones.
  • the transmitted data protected is payment data.
  • Payment data can for example comprise a credit card number, a password, or a one-time password.
  • two computer programs communicate with each other protected by cryptographic key(s) downloaded from a server.
  • the communication with said server might be encrypted using a purpose key.
  • the communication with said server might be authenticated using a purpose key.
  • the downloaded might be sym metric or asymmetric.
  • a first client application communicated with a server protected by purpose keys.
  • the first client application communicates with a second client application protected by purpose keys generated by the second client application's key generator.
  • the first client application gets the keys needed to communicate with the second client application from a server knowing how the key generator of the second client application is constructed.
  • a program communicates with a second program; the two programs verifies if they run on the same computer by sending profile data or something derived thereof to each other.
  • a secure communication channel is established between a client application and a server application.
  • a key exchange protocol is executed to establish an exchanged set of keys.
  • the key exchange protocol might be based on the Diffie-Hellman protocol.
  • the exchanged set of keys might be used to encrypt and/or authenticate data sent between the client applications and the server application.
  • a secure channel is established between two computer programs; at least one of them has an embedded key generator.
  • a key exchange protocol is executed to establish an exchanged set of keys.
  • the key exchange protocol might be based on the Diffie-Hellman protocol.
  • the exchanged set of keys might be used to encrypt and/or authenticate data sent between the client applications and the server application.
  • a secure communication channel is established between a server application and a client application.
  • a public asymmetric key is sent.
  • the party sending the public key has the corresponding private key.
  • One party generates a cryptographic key and encrypts it using one of the asymmetric keys; the encrypted key is sent to the other party which decrypts it using the other asymmetric key.
  • the algorithm used to perform the encryption/decryption might be RSA or ECC.
  • a purpose key generated by a key generator is used to encrypt data to be stored or to decrypt data that has been stored.
  • a purpose key generated by a key generator is used to generate an authentication tag on data to be stored or data that has been stored.
  • a tag can for example be written along with the data.
  • a read tag may be compared with the tag generated by the reader to verify if the stored data is authentic.
  • an encrypted file is created by the following procedure:
  • Payload is encrypted and authenticated using the generated keys and stored in the file.
  • the payload is decrypted using the encryption key. Encryption or authentication may be omitted if desired. Two key generator IVs may be used instead of one.
  • stored data is encrypted and/or authenticated with a key that depends on hardware profile data. This makes the files unreadable by a computer with another hardware profile than the one that wrote the file.
  • an encrypted file is created by the following procedure: • Two random key generator IVs are chosen.
  • the two random keys are encrypted (e.g. using XOR or an encryption algorithm).
  • the encrypted keys are stored in the file.
  • Payload is encrypted and authenticated using the random keys and stored in the file.
  • Encryption or authentication may be omitted if desired.
  • One purpose key may be used instead of two (also if both encryption and authentication is used; both keys may be encrypted using the same key).
  • One key generator IV may be used instead of two.
  • an encrypted file is created by the following procedure (also see figure 11):
  • a purpose key is generated by the key generator (KG in the figure) using the key generator IV.
  • a program authentication tag is created (by MAC in the figure) using the purpose key as MAC key.
  • Hardware profile data is read.
  • the hardware profile data is collected in groups. For each group o
  • the authentication tag and the hardware parameter group data string are hashed (by upper H in the figure).
  • the output from the hash function is XOR'ed with the encryption key (this way, the key is encrypted).
  • the resulting string is stored in the file.
  • the output from the hash function is hashed again (by lower H in the figure). This second-order hash string is stored in the file.
  • the payload is encrypted using the encryption key.
  • the encrypted string is stored in the file.
  • the file can be decrypted using the following procedure:
  • a purpose key is generated by the key generator using the key generator IV.
  • a program authentication tag is created using the purpose key as MAC key.
  • Hardware profile data is read.
  • the hardware profile data is collected is the same groups as when encrypting the file. For each group: o
  • the authentication tag and the hardware parameter group data string are hashed.
  • the output from the hash function is hashed again.
  • the output is compared to the second-order hash strings in the file. o If a matching second-order hash string is found in the file, the corresponding
  • XOR'ed key is read. This key is XOR'ed with the original hash string (first-order hash string) to obtain the encryption key.
  • the encrypted payload is decrypted using the found encryption key. If program integrity is not needed, the MAC function is removed and the purpose key is used directly as part of the input to the first (upper) hash function. If hardware binding is not needed, the output from the MAC function is used as encryption key; no hash strings or encrypted keys are stored in the file. Hardware parameter data may be manipulated prior to the first hashing. If just one hardware profile group is used, just use the output from the first hash function as key (no hash strings or keys are stored) or use it to encrypt the key (no hash strings are stored but the encrypted key is stored).
  • the purpose key may be replaced by a constant or the MAC function used in generating the authentication tag may be replaced by a hash function or the authentication tag may be omitted as input to the first hash function (i.e. only hardware profile data is input).
  • the key generator IV, second-order hash strings, and/or encrypted keys may be stored in the same file as the (encrypted) payload or in one or more other files. If the file is also to be authenticated, a second random key is chosen in the file generation step and two encrypted keys are stored instead of one for each second-order hash.
  • the encrypted keys may be encrypted by other functions than xor; for example by an encryption algorithm.
  • the input to the first hash function may be manipulated in different ways (e.g. by appending different strings) to obtain different hash strings for each key.
  • Several encrypted keys for each second-order hash may be stored, allowing to decrypt (or verify authenticity of) several files or parts of files.
  • Different files or parts of files encrypted using different keys may be decrypted by knowing different hardware profile data (e.g. more secret data may require more correct hardware parameters than less secret data).
  • a file encrypted by one copy of a client program can be re-encrypted to be accessible by another copy of a client program.
  • the file can be sent to the server, the server (knowing how both the first copy's and the second copy's key generator's compositions) can generate the keys needed to decrypt the file and encrypt it again for the second copy.
  • the encrypted key can be sent to the server, the server (knowing how both the first copy's and the second copy's key generator's compositions) can generate the keys needed to decrypt the key and encrypt it again for the second copy
  • a key generator is used to encrypt/decrypt and/or authenticate a cookie (e.g. used in a web browser or a web server).
  • a new version of a copy of a computer- executable program file is generated such that the new version has a key generator equivalent to the one of the old version.
  • an old version of a computer-executable program file downloads a new version with a key generator equivalent to the one of the old version.
  • an old version of a computer-executable program file in the form of an embedded object in a home page receives a message from a server application telling it to forward the browser to another page using an argument given by the server application.
  • This other page combined with the given arguments allows the web server to send a new version of the computer-executable program file with a key generator equivalent to the one of the old version.
  • a database containing at least two of: user ID, client program serial numbers, client program version number, and client program PRNG seeds is maintained.
  • the database is updated accordingly.
  • a client program is updated if certain criteria are fulfilled. For example, when a client program connects to a server, the client program sends an identification string to the server (e.g. containing its serial number). If the server decides that the client program needs to be updated, it sends a message to the client program saying that it should update itself. If the client program is a program embedded into a homepage, the auto update may be initialized by forwarding the containing page to another URL, the other URL initiates the update.
  • the browser Before a client program embedded into a home page is started, the browser (or another component on the client computer) will usually check if a newer version of the client program is available. The check is usually performed by contacting a server using HTTP or HTTPS. I n one embodiment of the present invention, the server decides if a newer version should be downloaded to the user based on at least one of: the content of a cookie, arguments given to the referrer site (can be detected through the "referrer" header line), or the "last-modified" header line.
  • a key generator is used to generate keys to decrypt and/or verify the authenticity of digital content, for example video, music, computer programs, or computer games.
  • a playback device e.g. a media player or a gaming console
  • This key generator can for example generate keys that can decrypt and/or verify the authenticity of digital content or generate keys that can decrypt keys that can be used to decrypt and/or verify the authenticity of digital content.
  • a distributor of digital content encrypts or generates an authentication tag using a random key.
  • This key is encrypted using a key generated by a server knowing how the user's application's key generator is constructed.
  • the protected content and the encrypted key are sent to the user, who can play it using his client application. If the user also wants to play the content on another playback device, he can apply (e.g. the content owner) for the key encrypted for the other device.
  • digital content is protected and distributed as illustrated on figure 12.
  • the user acquires a playback device (e.g. a media player) from a player vendor.
  • This playback device has an embedded key generator.
  • the player vendor informs a license manager about how the key generator is constructed such that the license manager can reproduce it.
  • the content is stored by the content vendor.
  • the content is encrypted and/or an authentication tag is generated (alternatively, this process can be performed ahead of the user's request).
  • the content is sent to the user e.g. over the Internet (or another network, a satellite link, a radio link, or on a media, e.g. a DVD).
  • the content can for be stored on the user's storage for later use or can be processed by the playback device right away.
  • the playback device acquires a key from the license manager (e.g. in encrypted form such that it can be decrypted using the playback device's key generator). This key can be stored for later use or can be used right away.
  • each copy or set of copies of a digital content is encrypted using a unique key.
  • a serial number, a product number, and/or another form of identification may be embedded into the encrypted content.
  • all copies of a digital content are encrypted using the same key.
  • a product number and/or another form of identification may be embedded into the content.
  • the playback device acquires keys (e.g. using the internet, a satellite link, or a radio link) for each playback of the content.
  • the playback device acquires keys that a stored and used for several playbacks of the content.
  • digital content is acquired; decrypted if it was acquired in encrypted form; and encrypted using a purpose key generated by a key generator.
  • a key generator is embedded into an authentication token (like e.g. RSA SecurelD).
  • This authentication token can for example generate one-time passwords used to authenticate a user.
  • a key generator is used to periodically generate new master keys in an authentication token.
  • the output of an authentication token is derived from a purpose key generated by a key generator.
  • a key generator is embedded into a device (e.g. a cell phone, a PDA, a gaming console, or a set top box), for example in the boot-strap code of the device.
  • data e.g. program code or content
  • a boot image stored in flash memory can be verified by bootstrap code stored in read-only memory to verify is the boot image is authentic and intact.
  • This can for example be achieved by appending a MAC tag to the boot image that can be verified using the key generator in the boot strap code.
  • This MAC tag can be generated by a server that knows how the key generator in the specific device is constructed.
  • a key generator is embedded into a device. Using this key generator, data can be decrypted or encrypted. For example, a boot image can be decrypted as part of the installation process, such that a user can download an encrypted boot image over the internet, this boot image can only be decrypted by a device having a given key generator.
  • a key generator embedded into a device is used to generate keys to secure a network link, secure stored data, or access digital content.
  • a key generator (or part thereof) is embedded into a hardware device or an electronic chip (e.g. a programmable electronic chip).
  • a financial application e.g. a online banking application, an online investment application, a payment site, or an automatic teller machine.
  • a computer game e.g. an online game, e.g. online poker.
  • a DRM application e.g. license manager or a media player.
  • a security application e.g. a VPN client, a remote desktop application, or an anti-virus application.
  • a distributed computing application e.g. to verify authenticity of client applications.
  • unique when used in this document on number or stings, it may includes randomly chosen numbers or string (e.g. generated by a PRNG) even though these can collide (i.e. there is a certain chance that the same number can be drawn more than once).
  • Figure 1 illustrates three customers communicating with their bank over the Internet using their computers.
  • the fourth user is an attacker.
  • the attacker has full control over the Internet and the users' computers.
  • FIG 2 illustrates the components involved in the communication between the user and the bank (i.e. the bank's internal computer systems).
  • the user and the bank are considered secure, but all other components can be under the influence of an attacker.
  • Figure 3 illustrates how the online banking program (the “netbank program”) can be secured by the present invention by having an embedded value or key generator.
  • This value or key generator is used to authenticate the online banking program towards the bank, whereby the bank can make sure that the online banking program is authentic.
  • the value or key generator may also be used to create a secure communication link between the program and the bank even if the computer or the Internet is compromised by an attacker.
  • the value or key generator may be used to encrypt/decrypt data stored locally (the "netbank data”), again even if the computer is compromised.
  • Figure 4 illustrates a key generator. Internally, it consists of two sub-functions: An extractor and a blender.
  • the extractor takes an extractor IV as input and generates an extracted key.
  • the extractor is usually unique for each copy of a program.
  • the blender takes an extracted key and a blender IV and generates a purpose key.
  • Figure 5 illustrates an extractor.
  • W 1 , W 2 , W 3 , and W 4 represents the initial values of the inner state words, which are being processed by n generator subfunction, F 1 , F 2 , ...F n .
  • the resulting values of the inner state words are processed by a function L to generate an extracted key.
  • Figure 6 illustrates an extractor.
  • An extractor IV is used to generate four initial values of the inner state words by the K function.
  • the extractor IV is also used to generate parameters for the generator subfunctions by the J function.
  • the generator subfunctions, F 1 , F 2 , ... F n manipulates the inner state words and uses each a constant, C 1 , C 2 , ...C n .
  • the resulting inner state words are processed by the L function to obtain an extracted key.
  • Figure 7 illustrates a client-server setup.
  • Client programs are generated by a client program generator.
  • the client generator stores the generated program files in a program file database and stores the generated program's serial number and PRNG seed in a SN/ Seed database.
  • the web server fetches one of the programs in the program database.
  • the transaction server can look up the PRNG seed using the programs serial number as key. Using the PRNG seed, the transaction server can reproduce the functionality of the key generator embedded into the client program.
  • Figure 8 illustrates a method for authenticating a computer-executable program file.
  • a key generator IV is sent to a key generator (KG), to obtain a purpose key.
  • the client program is processed by a function (F) and the resulting string is sent through a MAC function where the generated purpose key is used as MAC key.
  • the resulting MAC tag is used as an authentication tag.
  • Figure 9 illustrates a method for authenticating a computer-executable program file.
  • a key generator IV is sent to a key generator (KG), to obtain a purpose key.
  • the client program is divided into substrings. Each substring is processed by a hash function.
  • the outputs from the hash functions are sent through a MAC function where the generated purpose key is used as MAC key.
  • the resulting MAC tag is used as an authentication tag.
  • Figure 10 illustrates a method for generating an encryption key and an authentication key.
  • a key generator IV is sent to a key generator (KG), to obtain a purpose key.
  • the client program is divided into substrings. Each substring is processed by a hash function.
  • the outputs from the hash functions are sent through a MAC function where the generated purpose key is used as MAC key.
  • One string is appended to the output of the MAC function and the resulting string is hashed.
  • the result of this hash operation is used as an encryption key.
  • Another string is appended to the output of the MAC function and the resulting string is hashed.
  • the result of this hash operation is used as an authentication key.
  • Figure 11 illustrates a method for storing a file encryption key.
  • a key generator IV is stored in a file and is sent to a key generator (KG), to obtain a purpose key.
  • the computer- executable program file is processed by a MAC function where the generated purpose key is used as MAC key.
  • Hardware profile data is read on the computer the program runs on. This data is grouped.
  • Each hardware profile group is processed with the output of the MAC function by a first hash function (upper H).
  • the output from the first hash function is hashed again and the result is stored in the file.
  • the output form the first hash function is also used to encrypt a key.
  • the encrypted key is also stored in the file.
  • An encrypted key and an output of the second hash function (lower H) are stored for each hardware profile group.
  • Figure 12 illustrates a DRM system where a user acquires a playback device with an embedded key generator from a player vendor.
  • the player vendor sends information about the key generator to a license manager such that the license manager can reproduce the key generator's functionality.
  • Content is encryption and/or authenticated and sent to the user.
  • the user downloads an encrypted key from the license manager. This key can be decrypted by the playback device in order to achieve the key(s) needed to decrypt or verify authenticity of the content.
  • Figure 13 illustrates two functions (A and B) in a being merged into one.
  • the call from the code of the original function A to the code from the original function B is changed to a local call.
  • the return from the code of the original function B is replaced by a local return statement.
  • extra functionality is embedded into the resulting function in order to handle tasks previously handled by the runtime environment or operating system, e.g. allocating and feeing memory for temporary variables.
  • FIG 14 illustrates a computer program (C) and a server (D).
  • C has an embedded key generator (KG).
  • D has a key generator emulator (KGE). If D knows the identity of C (e.g. knows its serial number), it can look up the seed value used to generate the key generator embedded into C from the serial number and seed database. This knowledge can be used by D's key generator emulator to emulate Cs key generator. Thus, C and D can generate the same keys. These keys can be used to send data in protected form between C and D. This protection can consist of the data being encrypted and/or authenticated using key generated by Cs KG and D's KGE.
  • Figure 15 illustrates two computer programs (G and H) and a server (I). G and H each have an embedded unique key generator (KG).
  • I has a key generator emulator (KGE).
  • KGE key generator emulator
  • the key generator emulator can generate the same keys as the key generators in G and H provided that I knows the identity if G and H (e.g. by knowing their serial numbers).
  • the key generator emulator can look up the seed values used to generate the key generators in G and H in the serial number / seed database.
  • I can create a cryptographic key that can be sent in protected form (e.g. encrypted form) to both G and H (i.e. encrypted using keys that can be generated by the key generators of G and H respectively).
  • G and H shares the same key, they can send protected data between each other where this data is encrypted and/or authenticated using the shared key.
  • a method of fabricating computer-executable program files from a source code comprising the step of embedding, in each of the fabricated computer-executable program files, at least one value or means for generating at least one value, said value being uniquely selected or generated for each of the fabricated computer-executable program files, whereby all of the fabricated computer-executable program files are capable of carrying out instructions defined by the source code, and whereby each individual computer-executable program file is capable of generating a unique output, which depends on said uniquely selected or uniquely generated value.
  • a method according to embodiment 1 or 2 where the embedded means for generating at least one value depends on at least one embedded value.
  • a method where the process of fabricating computer-executable program files from a source code is divided into at least two steps; a first step of converting source code into at least one intermediate file is performed once and a later step of converting at least one intermediate file and optionally other files into a computer-executable program file is performed for each computer-executable program file.
  • a method according to any of embodiments 1 - 11 where the embedded means for generating at least one value comprises at least one extractor subfunctions, the extractor subfunctions have been selected from a set of available extractor subfunctions.
  • a method according to any of embodiments 1 - 11 where the embedded means for generating at least one value comprises at least one extractor subfunction.
  • a method according to any of embodiments 12 - 20 where at least one extractor subfunction comprises at least one of:
  • a method according to any of the preceding embodiments where information about how a computer-executable program file is generated is stored such that the computer-executable program file can be reproduced or its functionality or part thereof can be reproduced or simulated.
  • a method of fabricating computer-executable program files according to any of the preceding embodiments comprising the following steps: 1. choosing a PRNG seed,
  • a method according to any of the preceding embodiments where a new version of a computer-executable program file is sent to a user; the new version has the same embedded at least one value or means for generating at least one value as the previous version.
  • a method according to embodiment 59 where the obfuscation method comprises means for at least one of:
  • a method according to any of the preceding embodiments where a computer-executable program file with embedded at least one value or means for generating at least one value decrypts another computer-executable program file.
  • a method according to any of the preceding embodiments where a computer-executable program file with at least one embedded value or embedded means for generating at least one value contains program code that can read profile data, the profile data comprises at least one of: • brand, type, version, or serial number of a hardware component,
  • a method where a computer program (A) communicating with a computer-executable program file with at least one embedded value or embedded means for generating at least one value (B); A can read profile data related to B, the computer B runs on, or the user using B.
  • A can read profile data related to B, the computer B runs on, or the user using B.
  • both parties in a communication selects a part of a key generator IV; the parts are communicated; a key generator IV is derived in both ends from the parts; both parties uses the constructed key generator IV to derived a key that can be used for encryption/decryption or authentication.
  • an authentication tag is calculated on a computer program, a computer-executable program file, or a data file; the authentication key is derived from an embedded at least one value or means for generating at least one value, the authentication tag is compared to one stored with the program or data to verify if the program or data is authentic and if the stored tag was generated by someone with knowledge about the embedded at least one value or means for generating at least one value.
  • a method of generating a media player with at least one uniquely selected value or at least one value generated by uniquely selected means is used to play back digital content produced by a method according to any of the preceding embodiments.
  • An file encrypted using a key; the decryption key can be derived or decrypted using at an embedded at least one value or means for generating at least one value in a computer- executable program file fabricated according to any of the preceding embodiments.
  • Data sent over a network the data is encrypted by a computer-executable program file fabricated according to any of embodiments any of the preceding embodiments.
  • a computer program for fabricating computer-executable program files from source code comprising means for performing the method of any of the preceding embodiments.
  • a computer-readable data medium comprising a computer program according to embodiment 132.
  • a computer loaded with a computer program according to embodiment 132.
  • a computer-executable program file fabricated by a method according to any of embodiments 1 - 121.
  • a computer program comprising a computer-executable program file fabricated from a source code, the computer program including, in said computer-executable program file, at least one embedded value or means for generating at least one value, said value being uniquely selected or uniquely generated for the computer-executable program file, whereby the computer-executable program file is capable of carrying out instructions provided by the source code and of generating a unique output, which depends from said uniquely selected or uniquely generated value.
  • a computer-readable data medium comprising a computer program according to embodiment 137 or 138.
  • a computer program according to any of embodiments 137 - 140 where the embedded means for generating at least one value comprises at least one extractor subfunction.
  • a computer program according to any of embodiments 141 - 144 where at least one of the extractor subfunctions depends on a value derived from a key generator initialization vector (key generator IV) where the key generator IV is given as argument to the embedded means for generating at least one value.
  • a computer program according to any of embodiments 137 - 182 where a new version of a computer-executable program file is sent to a user; the new version has the same embedded at least one value or means for generating at least one value as the previous version.
  • a computer program according to any of embodiments 137 - 183 where a computer- executable program file with an embedded at least one value for means for generating at least one value downloads or in another way acquires another computer-executable program file with the same embedded at least one value for means for generating at least one value.
  • a computer program according to any of embodiments 137 - 185 where information about a program file's embedded at least one value or means for generating at least one value is stored; when the computer-executable program file is updated, this information is updated.
  • a computer program according to embodiment 188 where the obfuscation method comprises means for at least one of: • replacing a program instruction or a set of program instructions with at least one new program instruction with equivalent functionality,
  • the profile data comprises at least one of: • brand, type, version, or serial number of a hardware component,
  • a computer program according to any of embodiments 205 - 207 where one party in a communication selects a key generator IV; the key generator IV is sent to the other party; both parties uses the key generator IV to derive a key that can be used for encryption/decryption or authentication.
  • a computer program (G) according to any of embodiments 137 - 209 where data is sent in encrypted form between programs G and H where G and H both com municates securely with server / using cryptographic keys derived from G's and f/'s embedded at least one value or means for generating at least one value; the server / provides at least one cryptographic key to G and H to be used to encrypt/decrypt at least a part of the data sent between G and H.
  • a computer program (J) according to any of embodiments 137 - 210 where data is sent in authenticated form between programs Jand ACwhere Jand AC both communicates securely with server L using cryptographic keys derived from Js and ACs embedded at least one value or means for generating at least one value; the server L provides at least one cryptographic key to Jand ACto be used to authenticate at least a part of the data sent between Jand AC.
  • a computer program (M) according to any of embodiments 137- 211 where at least one cryptographic key is negotiated between programs M and N where M and N both com municates securely with server O using cryptographic keys derived from Ms and ⁇ /'s embedded at least one value or means for generating at least one value
  • a computer program (P) according to any of embodiments 137 - 209 where data is sent in encrypted form between programs Pand Q; Pderives the encryption/decryption key from its embedded at least one value or means for generating at least one value; Q receives the encryption/decryption key from a server.
  • a computer program (Q) according to any of embodiments 137 - 209 where data is sent in encrypted form between programs Pand Q; Pderives the encryption/decryption key from its embedded at least one value or means for generating at least one value; Q receives the encryption/decryption key from a server. 218.
  • a computer program (R) according to any of embodiments 137 - 209 where data sent between programs R and S is authenticated; R derives the authentication key from its embedded at least one value or means for generating at least one value; S receives the authenticate key from a server.
  • a computer program (S) according to any of embodiments 137 - 209 where data sent between programs R and S is authenticated; R derives the authentication key from its embedded at least one value or means for generating at least one value; S receives the authenticate key from a server.
  • a computer program according to embodiment 220 where the two com municating programs read profile data and compare these to verify that they run on the same computer.
  • a computer program according to any of embodiments 202 - 222 where the two computer programs communicating is a computer program and a software module loaded by the computer program.
  • a computer program according to embodiment 229 or 230 where the asymmetric key is a public RSA key or a private RSA key.
  • a computer program according to embodiment 229 or 230 where the asymmetric key is a public ECC key or a private ECC key.
  • a computer program according to any of embodiments 137 - 241 where credit card information is encrypted or decrypted using a cryptographic key derived from the embedded at least one value or means for generating at least one value.
  • a server according to embodiment 247 which has different versions of the computer program to be downloaded; the server decides which one to send according to predefined criteria.
  • An file encrypted using a key; the decryption key can be derived or decrypted using at an embedded at least one value or means for generating at least one value in a computer program according to any of embodiments 137 - 246.
  • Data sent over a network is encrypted using a key; the decryption key can be derived or decrypted using an embedded at least one value or means for generating at least one value in a computer program according to any of embodiments 137 - 246.
  • a computer on which at least one computer program according to any of embodiments 137 - 246 is stored or executed.
  • a method of generating a one-time password including the steps of any of embodiments 137 - 257.
  • a method of generating a one-time password in a device comprising a computer- executable program file fabricated from a source code, the computer program including, in said computer-executable program file, at least one embedded value or means for generating at least one value, said value being uniquely selected or uniquely generated for the computer-executable program file, whereby the computer-executable program file is capable of carrying out instructions provided by the source code and of generating a unique output, which depends from said uniquely selected or uniquely generated value, the method further comprising the step of processing said unique output to generate said one-time password.
  • a computer network comprising a server and a plurality of clients, wherein each client is loaded with a copy of a first computer program, and wherein the server is loaded with a second computer program, each copy of the first computer program comprising:
  • a method of generating a combined software component comprising: • providing at least two non-combined software components, which are intended to be combined by an operating system at runtime or in a runtime environment;
  • a method according to any of embodiments 268 - 272 where at least one of the added means for handling tasks that otherwise would be handled by the runtime environment or operating system is means for handling memory allocation, stack operations, or errors.
  • a software component combined according to any of embodiments 268 - 280.
  • a computer-readable data medium comprising a software component according to embodiment 281.
  • a server com municating with a client computer program comprising a com put er- executable program file fabricated from a source code, the computer program including, in said computer-executable program file, at least one embedded value or means for generating at least one value, said value being uniquely selected or uniquely generated for the computer-executable program file, whereby the computer-executable program file is capable of carrying out instructions provided by the source code and of generating a unique output, which depends from said uniquely selected or uniquely generated value.
  • a server according to embodiment 287 with functionality that allows it to recreate at least one of
  • a server according to embodiment 287 that can load from a database or file at least one of
  • a server according to any of embodiments 287 - 289 that can load from a database or file the PRNG seed that was used to generate the string of pseudo-random bits that determined at least one of
  • a server according to embodiment 287 that can load and use a software module containing at least one of: • at least one of the at least one embedded values, and
  • a server A server according to any of embodiments 287 - 293 where the recreated or loaded at least one value or means for generating at least one value is kept ready-to-use for a certain period of time after the session with the relevant program has ended such that the recreated or loaded at least one value or means for generating at least one value is ready for use in case of the given program connects to the server again within the given period of time.
  • a server according to any of embodiments 295 - 301 where a Client Program connects to the server to download information about its rights.
  • a server according to any of embodiments 295 - 303 where a Client Program connects to the server to download cryptographic keys that can be used to encrypt, decrypt, or authenticate data.
  • a server according to embodiment 304 that refuses to provide keys to access types of data or copies of data that the Client Program is not allowed to access.
  • a server according to any of embodiments 295 - 305 where a log file is maintained with information about which Client Programs have been given which rights.
  • a server according to any of embodiments 295 - 306 where a log file is maintained with information about which Client Programs have been given which cryptographic keys.
  • a server according to any of embodiments 287 -311 where an asymmetric key is encrypted or decrypted using a cryptographic key derived from an embedded at least one value or means for generating at least one value in the Client Program.
  • a server according to any of embodiments 287 - 312 where an asymmetric key is authenticated using a cryptographic key derived from an embedded at least one value or means for generating at least one value in the Client Program.
  • a server according to embodiment 312 or 313 where the asymmetric key is a public RSA key or a private RSA key.
  • a server according to embodiment 312 or 313 where the asymmetric key is a public ECC key or a private ECC key.
  • a server according to any of em bodiments 287 - 323 where credit card inform ation is encrypted or decrypted using a cryptographic key derived from an em bedded at least one value or m eans for generating at least one value in the Client Program .
  • a server according to any of em bodim ents 287 - 324 where payment authorization data is encrypted or decrypted using a cryptographic key derived from an em bedded at least one value or m eans for generating at least one value in the Client Program .
  • a com puter program com m unicating with a server according to any of em bodim ents 287 - 327.
  • Data sent over a network the data is authenticated by a server according to any of em bodiments 287 - 327.
  • a computer-readable data medium comprising server software according to any of embodiments 287 - 327.
  • a device communicating with a server according to any of embodiments 287 - 327.

Abstract

L'invention concerne un procédé pour protéger un programme informatique contre une manipulation et pour protéger sa communication avec d'autres programmes contre une écoute clandestine et une modification. Le procédé comporte la création de copies de programme individualisées à différents groupes d'utilisateurs, l'insertion de clés cryptographiques individuelles ou la dérivation de clés cryptographiques individuelles à partir du code de programme, l'obscurcissement du code de programme et l'auto-authentification du programme vers d'autres programmes. Le procédé est approprié pour la protection d'une application de banque en ligne, d'investissement en ligne, de divertissement en ligne, de gestion de droits numériques et d'autres applications de commerce électronique.
PCT/EP2007/060056 2006-09-21 2007-09-21 Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source WO2008034900A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP07803589A EP2064648A1 (fr) 2006-09-21 2007-09-21 Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source
US12/311,181 US20090249492A1 (en) 2006-09-21 2007-09-21 Fabrication of computer executable program files from source code
PCT/EP2007/063983 WO2008071795A2 (fr) 2006-12-15 2007-12-14 Authentification de données numériques
EP07857617A EP2122530A2 (fr) 2006-12-15 2007-12-14 Authentification de données numériques
US12/448,249 US8468351B2 (en) 2006-12-15 2007-12-14 Digital data authentication
US13/889,764 US8949607B2 (en) 2006-12-15 2013-05-08 Digital data authentication

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
DKPA200601221 2006-09-21
DKPA200601221 2006-09-21
US87495506P 2006-12-15 2006-12-15
US60/874,955 2006-12-15
US90746507P 2007-04-03 2007-04-03
US60/907,465 2007-04-03
US93576907P 2007-08-30 2007-08-30
DKPA200701237 2007-08-30
US60/935,769 2007-08-30
DKPA200701237 2007-08-30

Publications (1)

Publication Number Publication Date
WO2008034900A1 true WO2008034900A1 (fr) 2008-03-27

Family

ID=38819279

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/060056 WO2008034900A1 (fr) 2006-09-21 2007-09-21 Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source

Country Status (2)

Country Link
EP (1) EP2064648A1 (fr)
WO (1) WO2008034900A1 (fr)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009019981A1 (de) 2009-05-05 2010-11-11 Giesecke & Devrient Gmbh Verfahren zum Schutz von auf einem tragbaren Datenträger gespeicherter Software und tragbarer Datenträger
US20100325446A1 (en) * 2009-06-19 2010-12-23 Joseph Martin Mordetsky Securing Executable Code Integrity Using Auto-Derivative Key
FR2947934A1 (fr) * 2009-07-08 2011-01-14 Sfr Procede de tracabilite et d'imputabilite dynamiques des echanges dans un environnement ouvert de type internet
CN102004887A (zh) * 2010-12-27 2011-04-06 用友软件股份有限公司 程序保护方法和装置
EP2434424A1 (fr) * 2010-09-27 2012-03-28 Kobil Systems GmbH Procédé d'augmentation de la sécurité de services en ligne relevant de la sécurité
US8160962B2 (en) 2007-09-20 2012-04-17 Uniloc Luxembourg S.A. Installing protected software product using unprotected installation image
US8201248B2 (en) 2008-02-18 2012-06-12 Codesealer Aps Authenticating a web page with embedded javascript
US20120198553A1 (en) * 2009-09-14 2012-08-02 Junko Suginaka Secure auditing system and secure auditing method
US8446834B2 (en) 2011-02-16 2013-05-21 Netauthority, Inc. Traceback packet transport protocol
US8881280B2 (en) 2013-02-28 2014-11-04 Uniloc Luxembourg S.A. Device-specific content delivery
US8949954B2 (en) 2011-12-08 2015-02-03 Uniloc Luxembourg, S.A. Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account
CN104917738A (zh) * 2014-03-14 2015-09-16 陈衡 金融平台数据处理方法和系统
WO2015139950A1 (fr) * 2014-03-17 2015-09-24 Bankinter S.A Système de protection automatisée et personnalisée pour applications mobiles
FR3020888A1 (fr) * 2014-05-12 2015-11-13 Morpho Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application
US9564952B2 (en) 2012-02-06 2017-02-07 Uniloc Luxembourg S.A. Near field authentication through communication of enclosed content sound waves
US10200345B2 (en) 2013-10-29 2019-02-05 Uniloc 2017 Llc Electronic mail sender verification
US10206060B2 (en) 2012-01-04 2019-02-12 Uniloc 2017 Llc Method and system for implementing zone-restricted behavior of a computing device
US10402557B2 (en) 2014-09-10 2019-09-03 Uniloc 2017 Llc Verification that an authenticated user is in physical possession of a client device
EP4167111A1 (fr) * 2021-10-12 2023-04-19 Planora Oy Procédé et appareil de préparation de logiciel unique

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999018490A1 (fr) * 1997-10-04 1999-04-15 I.P.R. Co. (21) Limited Procede et appareil de securite des donnees numeriques
US6006328A (en) * 1995-07-14 1999-12-21 Christopher N. Drake Computer software authentication, protection, and security system
US20010051928A1 (en) * 2000-04-21 2001-12-13 Moshe Brody Protection of software by personalization, and an arrangement, method, and system therefor
US6668325B1 (en) * 1997-06-09 2003-12-23 Intertrust Technologies Obfuscation techniques for enhancing software security
EP1513113A1 (fr) * 2003-09-03 2005-03-09 France Telecom Système et procédé pour la communication sécurisée basé sur cartes à puce
US20050188214A1 (en) * 2004-02-23 2005-08-25 Worley John S. Authenticatable software modules

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006328A (en) * 1995-07-14 1999-12-21 Christopher N. Drake Computer software authentication, protection, and security system
US6668325B1 (en) * 1997-06-09 2003-12-23 Intertrust Technologies Obfuscation techniques for enhancing software security
WO1999018490A1 (fr) * 1997-10-04 1999-04-15 I.P.R. Co. (21) Limited Procede et appareil de securite des donnees numeriques
US20010051928A1 (en) * 2000-04-21 2001-12-13 Moshe Brody Protection of software by personalization, and an arrangement, method, and system therefor
EP1513113A1 (fr) * 2003-09-03 2005-03-09 France Telecom Système et procédé pour la communication sécurisée basé sur cartes à puce
US20050188214A1 (en) * 2004-02-23 2005-08-25 Worley John S. Authenticatable software modules

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BELLARE M ET AL INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH: "KEYING HASH FUNCTIONS FOR MESSAGE AUTHENTICATION", 18 August 1996, ADVANCES IN CRYPTOLOGY - CRYPTO '96. 16TH. ANNUAL INTERNATIONAL CRYPTOLOGY CONFERENCE. SANTA BARBARA, AUG. 18 - 22, 1996. PROCEEDINGS, PROCEEDINGS OF THE ANNUAL INTERNATIONAL CRYPTOLOGY CONFERENCE (CRYPTO), BERLIN, SPRINGER, DE, PAGE(S) 1-15, ISBN: 3-540-61512-1, XP000626584 *

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8160962B2 (en) 2007-09-20 2012-04-17 Uniloc Luxembourg S.A. Installing protected software product using unprotected installation image
US8789199B2 (en) 2008-02-18 2014-07-22 Codesealer Aps Authenticating a web page with embedded javascript
US8201248B2 (en) 2008-02-18 2012-06-12 Codesealer Aps Authenticating a web page with embedded javascript
DE102009019981A1 (de) 2009-05-05 2010-11-11 Giesecke & Devrient Gmbh Verfahren zum Schutz von auf einem tragbaren Datenträger gespeicherter Software und tragbarer Datenträger
US20100325446A1 (en) * 2009-06-19 2010-12-23 Joseph Martin Mordetsky Securing Executable Code Integrity Using Auto-Derivative Key
EP2264639A3 (fr) * 2009-06-19 2015-03-11 Uniloc Usa, Inc. Sécurisation de l'intégrité de code exécutable utilisant une clé dérivative automatiquement
EP2284751A1 (fr) * 2009-07-08 2011-02-16 Societé Française du Radiotéléphone Procédé de traçabilité et d'imputabilité dynamiques des échanges dans un environnement ouvert de type Internet
FR2947934A1 (fr) * 2009-07-08 2011-01-14 Sfr Procede de tracabilite et d'imputabilite dynamiques des echanges dans un environnement ouvert de type internet
US20120198553A1 (en) * 2009-09-14 2012-08-02 Junko Suginaka Secure auditing system and secure auditing method
EP2434424A1 (fr) * 2010-09-27 2012-03-28 Kobil Systems GmbH Procédé d'augmentation de la sécurité de services en ligne relevant de la sécurité
DE102010037784B4 (de) * 2010-09-27 2014-07-31 Kobil Systems Gmbh Verfahren zur Erhöhung der Sicherheit von sicherheitsrelevanten Online Diensten
CN102004887A (zh) * 2010-12-27 2011-04-06 用友软件股份有限公司 程序保护方法和装置
US8755386B2 (en) 2011-01-18 2014-06-17 Device Authority, Inc. Traceback packet transport protocol
US8446834B2 (en) 2011-02-16 2013-05-21 Netauthority, Inc. Traceback packet transport protocol
US8949954B2 (en) 2011-12-08 2015-02-03 Uniloc Luxembourg, S.A. Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account
US10206060B2 (en) 2012-01-04 2019-02-12 Uniloc 2017 Llc Method and system for implementing zone-restricted behavior of a computing device
US10068224B2 (en) 2012-02-06 2018-09-04 Uniloc 2017 Llc Near field authentication through communication of enclosed content sound waves
US9564952B2 (en) 2012-02-06 2017-02-07 Uniloc Luxembourg S.A. Near field authentication through communication of enclosed content sound waves
US8881280B2 (en) 2013-02-28 2014-11-04 Uniloc Luxembourg S.A. Device-specific content delivery
US9294491B2 (en) 2013-02-28 2016-03-22 Uniloc Luxembourg S.A. Device-specific content delivery
US10200345B2 (en) 2013-10-29 2019-02-05 Uniloc 2017 Llc Electronic mail sender verification
CN104917738B (zh) * 2014-03-14 2018-03-16 陈衡 金融平台数据处理方法和系统
CN104917738A (zh) * 2014-03-14 2015-09-16 陈衡 金融平台数据处理方法和系统
WO2015139950A1 (fr) * 2014-03-17 2015-09-24 Bankinter S.A Système de protection automatisée et personnalisée pour applications mobiles
US10616262B2 (en) * 2014-03-17 2020-04-07 Bankinter, S.A. Automated and personalized protection system for mobile applications
FR3020888A1 (fr) * 2014-05-12 2015-11-13 Morpho Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application
US10402557B2 (en) 2014-09-10 2019-09-03 Uniloc 2017 Llc Verification that an authenticated user is in physical possession of a client device
EP4167111A1 (fr) * 2021-10-12 2023-04-19 Planora Oy Procédé et appareil de préparation de logiciel unique

Also Published As

Publication number Publication date
EP2064648A1 (fr) 2009-06-03

Similar Documents

Publication Publication Date Title
US20090249492A1 (en) Fabrication of computer executable program files from source code
WO2008034900A1 (fr) Fabrication de fichiers de programme exécutables par ordinateur à partir d'un code source
US8949607B2 (en) Digital data authentication
EP3387813B1 (fr) Dispositif mobile ayant un environnement d'exécution sécurisé
EP2491510B1 (fr) Système et procédé de distribution pour distribuer des informations numériques
US9853957B2 (en) DRM protected video streaming on game console with secret-less application
Lazar et al. Why does cryptographic software fail? A case study and open problems
Kim et al. Predictability of android openssl's pseudo random number generator
US20170243203A1 (en) Crm security core
CN110401615B (zh) 一种身份认证方法、装置、设备、系统及可读存储介质
US20070277037A1 (en) Software component authentication via encrypted embedded self-signatures
WO2008053279A1 (fr) Ouvrir une session sur un dispositif utilisateur vers un serveur
EP3292654B1 (fr) Approche de sécurité pour stocker des justificatifs d'identité destinés à une utilisation hors ligne et un contenu de coffre protégé contre la copie dans des dispositifs
CN111124453A (zh) 一种终端设备固件程序升级方法
Feng et al. FIDO Gets Verified: A Formal Analysis of the Universal Authentication Framework Protocol
EP3058498B1 (fr) Noyau de sécurité crm
US11720693B2 (en) System and method for securely transferring data
CN108235807B (zh) 软件加密终端、支付终端、软件包加密及解密方法及系统
CN112597453A (zh) 程序代码加密解密方法和装置
Kumbhar et al. Hybrid Encryption for Securing SharedPreferences of Android Applications
Dhanasekaran et al. Payment security mechanism of intelligent mobile terminal
US20220284113A1 (en) System and method for securely transferring data using encryption keys
US11522707B2 (en) System and method for detecting compromised devices
Raju et al. Secure Messaging with in-app user defined schemes
JP2023533734A (ja) プログラマブルデバイスを遠隔でプログラミングするための方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07803589

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2007803589

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007803589

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12311181

Country of ref document: US