WO2010057546A1 - Appareil de vérification et de génération d'un jeton crypté et procédés pour celui-ci - Google Patents

Appareil de vérification et de génération d'un jeton crypté et procédés pour celui-ci Download PDF

Info

Publication number
WO2010057546A1
WO2010057546A1 PCT/EP2009/006295 EP2009006295W WO2010057546A1 WO 2010057546 A1 WO2010057546 A1 WO 2010057546A1 EP 2009006295 W EP2009006295 W EP 2009006295W WO 2010057546 A1 WO2010057546 A1 WO 2010057546A1
Authority
WO
WIPO (PCT)
Prior art keywords
bits
token
encrypted
product
plain
Prior art date
Application number
PCT/EP2009/006295
Other languages
English (en)
Inventor
Daniel Bister
Jens Fangmeier
Andreas Eckleder
Original Assignee
Nero Ag
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 Nero Ag filed Critical Nero Ag
Priority to EP09778224A priority Critical patent/EP2353251B1/fr
Publication of WO2010057546A1 publication Critical patent/WO2010057546A1/fr
Priority to US13/112,367 priority patent/US8719583B2/en
Priority to US14/269,046 priority patent/US9043606B2/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/304Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy based on error correction codes, e.g. McEliece
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/321Cryptographic 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 involving a third party or a trusted authority
    • H04L9/3213Cryptographic 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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16Obfuscation or hiding, e.g. involving white box
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/26Testing cryptographic entity, e.g. testing integrity of encryption key or encryption algorithm

Definitions

  • the present invention relates to an apparatus for verifying a validity of an encrypted token and to an apparatus for generating such an encrypted token as well as to methods for verifying such an encrypted token and a method for generating an encrypted token.
  • Embodiments of the invention particularly relate to an encrypted token associated to a product, for example, a computer program or software product.
  • the encrypted token maybe a serial number of the software product.
  • tokens to authorize access to a technical system are widely used, for example, in the information technology (IT). While such tokens exist as either personalized or as anonymous access keys, one of the most crucial aspects is the security.
  • public key cryptography is used to digitally sign or encrypt the token such as to allow an access control mechanism of a technical system to verify the authenticity of said token.
  • the length of the key (the number or size in bits) used for creating the signature/encrypting the token corresponds directly to the achieved level of security.
  • the maximum size of such tokens is limited to a certain number of bits. This is to ensure that they are easy to transmit or comfortable for handling, e.g. when the token has to be entered manually into a technical system.
  • a signed user specific token consists of an arbitrary number of payload bits and a minimum number of signature bits determined by the signing/encryption algorithm used.
  • Insecure user specific tokens or user access keys for technical systems e.g. for software products, can lead to an illegal use of such technical systems.
  • Based on such an insecure token, an illegal user may be able to build an own key or token generator and thus, create own access keys for the technical system.
  • signing/encryption algorithms should be used which guarantee a high level of security.
  • cryptographic methods are applied to generate encrypted user specific tokens and to verify such user specific tokens.
  • public/private key cryptography is used for encrypting or decrypting such user specific tokens by means of a private and a public key.
  • Typical public key cryptosystems are, for example, the RSA-cryptosystem, the McEliece cryptosystem applying a Goppa code or the Niederreiter-cryptosystem. These cryptosystems are asymmetric key algorithms with a public key and a private key. These keys are used to encrypt and decrypt messages, for example, user specific tokens or access keys.
  • tj represents the value, which is obtained if Sj is encrypted with the secret key.
  • the signature of the document D is then ti
  • Document D with the signature is the value D I ti I i.
  • the encrypted serial number comprises an average length of 198 bits according to the method described from Courtois et al.
  • the inventive methods and apparatus described herein generate for a serial number with 54 bit information normally an encrypted serial number with 140 bits.
  • the length of the encrypted serial number or the encrypted token may be shorter than by the proposed method described by Courtois et al.
  • the method described by Courtois et al. does not propose a concept of scalable security.
  • Courtois et al. describes the possibility to change the proposed method in order to reduce the length of the encrypted token to an average of 159 bits.
  • the computing time in order to verify the validity of the encrypted serial number is drastically increased up to 30 seconds, hi contrast, the computing time for the validation of an encrypted token according to embodiments of the invention may only comprise some milliseconds.
  • the present invention seeks to provide an apparatus for verifying a validity of an encrypted token, an apparatus for generating an encrypted token and methods for doing same in an improved way.
  • the improvement may relate to the level of security, a scalable security level associated to a product or different functionalities of a product, a small bit size of the generated encrypted token and a less calculation time for verifying the validity of an encrypted token.
  • an apparatus for verifying a validity of an encrypted token associated to a product may comprise a decryptor for decrypting an encrypted token using a decryption key to obtain a decrypted token having information bits related to the product and structure bits.
  • it may comprise an evaluator for evaluating whether the structure bits fulfill a predetermined condition, wherein the encrypted token is verified to be valid when the predetermined condition is fulfilled or is not verified to be valid when the predetermined condition is not fulfilled.
  • an apparatus for generating an encrypted token associated to a product comprises a plain token generator for generating a plain token, wherein the plain token generator is configured to generate a plain token having information bits related to the product and having structure bits related to a predetermined condition for verifying a validity of the encrypted token and wherein the plain token generator is configured to generate structure bits, which fulfill the predetermined condition.
  • the apparatus further comprises an encryptor for encrypting the plain token using an encryption key to obtain an encrypted token.
  • a method for generating an encrypted token associated to a product and a method for verifying a validity of an encrypted token associated to a product are described.
  • a user specific token or an encrypted token with scalable security can be generated. With a given number of bits and a given payload or useful information, all bits of a token not required for encoding the payload can be used to increase the security with respect to an illegal attack.
  • a variable number of structure bits being part of the decrypted token may be used to achieve a scalable security.
  • a predetermined condition for verifying the validity of an encrypted token may depend on random bits being part of the decrypted token and which are required to generate an encrypted token.
  • the level of the security of an encrypted token generated by the inventive apparatus for generating an encrypted token and by the method for generating an encrypted token may depend on the price, the complexity or the number of features or functions of a product whose access is permitted by the encrypted token.
  • a public key may be used to decrypt an encrypted token and a private key may be used to generate an encrypted token based on a plain token.
  • Fig. 1 shows a block diagram of an apparatus for verifying a validity of an encrypted token associated to a product according to an embodiment
  • Fig. 2a shows a block diagram of an apparatus for verifying a validity of an encrypted token comprising a product access processor according to an embodiment of the invention
  • Fig. 2b shows a block diagram of a product access processor being part of the apparatus for verifying a validity of an encryptor token according to another embodiment
  • Fig. 3 shows a block diagram of an apparatus for verifying a validity of an encrypted token associated to a product additionally comprising a data parser according to another embodiment of the invention
  • Fig. 4 shows a block diagram of an evaluator being part of the apparatus for verifying a validity of an encrypted token according to an embodiment
  • Fig. 5 shows a schematic block diagram of an encrypted token and a decrypted token
  • Fig. 6 shows a block diagram of an apparatus for generating an encrypted token associated to a product according to an embodiment
  • Fig. 7 shows a block diagram of a plain token generator being part of the apparatus for generating an encrypted token according to another embodiment of the invention.
  • Fig. 8 shows an example for generating an encrypted user specific token
  • Fig. 9 shows a flow chart of the method for verifying a validity of an encrypted token associated to a product according to an embodiment
  • Fig. 10 shows a flow chart of the method for generating an encrypted token associated to a product according to an embodiment
  • Fig. 11 shows a flow diagram of the method for generating an encrypted token according to another embodiment.
  • FIG. 1 an apparatus 100 for verifying a validity of an encrypted token 10 associated to a product according to an embodiment of the invention is depicted in a block diagram.
  • the apparatus 100 comprises a decryptor 20 for decrypting an encrypted token 10 using a decryption key 30 to obtain a decrypted token 40 having information bits 42 related to the product and structure bits 44.
  • the apparatus 100 comprises an evaluator 50 for evaluating whether the structure bits 44 fulfill a predetermined condition, wherein the encrypted token 10 is verified to be valid when the predetermined condition is fulfilled or is not verified to be valid when the predetermined condition is not fulfilled.
  • An encrypted token associated to a product or a technical system is fed automatically or manually to a decryptor for decrypting the encrypted token.
  • the encrypted token 10 may be associated to a software product or a computer program, but it is also applicable to other products or technical systems.
  • the encrypted token 10 may be a serial number of this software product. A user who wants to install this software product on his computer may have to enter his user specific encrypted token or serial number in a computer to work with the software.
  • a serial number may comprise a sequence of numbers and numerals, e.g. A4HK-7BCH- PE23-KL7H-YC72.
  • the encrypted serial number may be decoded in a binary number by the decryptor. Then the encrypted binary number can be decrypted by means of the decryptor using a public/private key method.
  • the set of serial numbers can be divided in two disjunctives sets - the set G of valid serial numbers and the set U of invalid serial numbers. If serial numbers are used two algorithms are necessary, first a validation algorithm to prove whether a serial number is valid and second a generation algorithm which is able to generate the set G of valid serial numbers.
  • a decryptor 20 decrypts the encrypted token by means of a decryption key to obtain the corresponding decrypted token.
  • the decryptor 20 may be configured to perform a certain method for decrypting an encrypted token.
  • the decryptor 20 may be configured to use a public/private key cryptosystem.
  • a public/private key cryptosystem may, for example, be the Niederreiter cryptosystem.
  • other public/private key cryptosystems may be used, e.g. the RSA cryptosystem, the McEliece cryptotsystem etc.
  • the decryptor 20 decrypts the encrypted token by means of the public key of the cryptosystem.
  • the public key may be stored on a (online-) database, which is accessible for everybody, i.e. the public.
  • the public key may be allocated to the public by the vendor of a software product.
  • the same public key may be stored on a storage medium, for example, a CD, DVD, etc. on which the software package is stored.
  • a user of the software package may now enter the serial number of the software product on the keyboard of his computer and the decryptor algorithm may decrypt, by means of the public key, which may be stored on the storage medium or in the software program or which may be downloaded from a public accessible database, the encrypted token.
  • the decryptor 20 decrypts the encrypted token using a decryption key 30 to obtain a decrypted token 40.
  • This decrypted token comprises information bits 42, wherein the information bits relate to the product, for example, to the software release or version number of the software product and to structure bits 44.
  • the number of structure bits 44 may be related to the level of security for the associated product, for example, to the software product.
  • the decryptor 20 is configured to decrypt the encrypted token 10 so that the decrypted token 40 comprises a larger number of bits than the encrypted token 10.
  • the decryptor 20 may make use of a Niederreiter cryptosystem in order to decrypt the encrypted token so that the decrypted token comprises a larger number of bits than the encrypted token.
  • the evaluator 50 may be configured to evaluate whether the structure bits in the decrypted token 40 fulfill a predetermined condition. If the predetermined condition of the structure bits is fulfilled, the encrypted token is verified to be valid. This means that if the encrypted token, for example, the serial number for a software product is verified to be valid, a user of the software gains access to install or to use the software product, hi contrast, the encrypted token or the serial number is not verified to be valid when the predetermined condition is not fulfilled. As a consequence, a user cannot use the software product.
  • Such a predetermined condition which is proven by the evaluator 50, may, for example, be a certain bit combination. Such a predetermined condition may, for example, be that a first portion of the structure bits is a copy of another portion of the decrypted token and the remaining bits comprise "1" or "0".
  • the evaluator 50 may comprise an evaluation algorithm, which checks whether the structure bits 44 comprise the required structure, i.e. the predetermined condition. If this condition is fulfilled, then the encrypted token or serial number is valid.
  • FIG. 2a another block diagram of an apparatus 100 for verifying a validity of an encrypted token 10 associated to a product according to an embodiment of the invention is depicted, hi this embodiment, the apparatus 100 further comprises a product access processor 60.
  • This product access processor 60 is configured for interpreting the information bits 42 of the decrypted token 40 and for determining a level of product access in accordance with information bits when the encrypted token 10 is verified to be valid.
  • the information bits may carry information concerning the product.
  • Such information about a product for example, software product, may concern certain features or functionalities of the software product.
  • a first bit of the information bits 42 can, for example, be related to a software option as to whether a user of the software product is allowed to play Blu-Ray discs with the software product, a second bit of the information bits may, for example, be determine as to whether the user is allowed to burn a Blu-Ray disc.
  • the information bits can be related to the product, and according to some embodiments, to product-related functions or features.
  • Such a feature may be, for example, a test period time for a free trial version of the software product or the like.
  • the product access processor 60 is configured to process a variable number of bits of the decryptor token. Furthermore it is configured to determine a higher level of product access when the number of information bits 42 is low and to determine a lower level of product access when the number of information bits 42 is comparatively high.
  • a higher level of product access may allow a user of the product, e. g. the software product, to use more, more expensive or more complicated functions of the product.
  • a lower level of product access may allow a user to use only less, less expensive or less complicated functions of the product.
  • the number of information bits in the decrypted token may be varying.
  • a high level of product access may be granted to a user and if a number of information bits is comparatively high only a low level of product access is granted.
  • a higher level of product access may be related to more functions or features of a product, more expensive functions or features or more complicated functions or features of the product. Accordingly, a lower level of product access allows a user the use of less functions or features, less expensive functions or features or less complicated functions or features of the product.
  • a higher level of product access may be related to an importance of the functionality for the majority of users of the product.
  • the storage of a document written with a text processing software on a computer may be such an important feature of a software product. If the decrypted token comprises a low number of information bits, a user of the text processing software may be allowed to store a written document and if the decrypted token comprises a higher number of information bits, the storage of written documents may be prohibited.
  • the product access processor 60 may comprise a processor 62, wherein the processor 62 may determine or grant a level of product access depending on the number of information bits and depending whether the encrypted token has been verified to be valid by the evaluator 50.
  • a product 80 may comprise different features or functionalities Fl to F5.
  • Such a feature or functionality for a software product may be, as already described above, for example, the possibility to burn a BIu- Ray disc, to read a Blue Ray disc, to store information, etc.
  • the decrypted token 40 comprises nine information bits (bit 1 to 9).
  • the product access processor 60 is configured to allow a user, based on a comparatively higher number of information bits (bits 1 to 12) a lower level of product access.
  • the processor 62 may be configured to allow a user, based on the twelve information bits 1 to 12 and the information concerning the validity of the encrypted token, the usage of a second subset S2 for a user.
  • the second subset S2 may comprise a lower level of product access, for example, only the functions Fl and F2 of the software product 80.
  • FIG. 3 A further embodiment of an apparatus 100 for verifying a validity of an encrypted token 10 associated to a product is shown in Fig. 3.
  • the apparatus 100 comprises a data parser 70 for parsing the decrypted token 40.
  • the data parser 70 is configured to determine a variable number of structure bits 44 depending on at least a portion of the decrypted token.
  • the data parser 70 is configured to identify the structure bits in the decrypted token 40 for the evaluator 50. Then the evaluator tries to evaluate the structure bits based on the identified structure bits.
  • the encrypted token 10 with the encrypted section 10a may additionally comprise a clear bit section 46.
  • the clear bit section 46 can comprise information on the product, which is not related to a level of product access. Such information may, for example, be a product version number, e.g., a software-release number or a production date.
  • the decryptor 20 is configured to only decrypt the encrypted section 10a of the encrypted token 10. This means that the decryptor does not decrypt the clear bit section 46 with the clear bits.
  • a data parser 70 may be configured for parsing the decrypted token 40 or a clear bit section 46 attached to the encrypted token 10.
  • the data parser may then be configured for determining a variable number of structure bits 44 depending on at least a portion of the decrypted token 40 or the clear data portion 46.
  • the data parser 70 is configured to identify the structure bits in the decrypted token 40 and provide the structure bits or information regarding the structure bits 44 to the evaluator 50. In other words, the data parser identifies the structure bits within the decrypted token. These structure bits are fed to the evaluator so that the evaluator 50 can check whether the structure bits fulfill the above-mentioned predetermined condition.
  • the decrypted token may additionally comprise the unchanged clear bits 46, i.e., the clear bits in the plain - or decrypted token and in the encrypted token are identical. Information which is stored in the clear bits is visible for a user. By contrast, the information of the information bits in the encrypted token is concealed from a user.
  • a block diagram of an evaluator 50 for evaluating whether the structure bits 44 fulfill a predetermined condition is shown.
  • the evaluator 50 comprises a comparator 56, which compares a predetermined bit combination which represents the predetermined condition, with the structure bits 44 from the decrypted token 40.
  • the comparator 56 compares the structure bits 44 and other bits 47 of the decrypted token 40.
  • the evaluator 50 may comprise at least one processor, which is configured to derive a value from the structure bits 44 or other bits 47 included in the decrypted token 40, which is then compared with a predetermined condition in the comparator 46.
  • the evaluator 50 may be configured to compare a value or a bit structure derived from the other bits 47 in the comparator 56 with a predetermined bit structure or a predetermined condition in order to distinguish whether the encrypted token 10 is valid or not. This means that the evaluator 50 outputs information concerning the validity of the encrypted token.
  • the evaluator 50 may be configured to compare a variable number of structure bits 44 or other bits 47.
  • the structure bits in the decrypted token may be identified by the data parser 70 as described in context to Fig. 3.
  • the evaluator may be configured to compare the structure bits and/or other bits of the decrypted token with the predetermined condition, for example, by means of a comparator. The result of the comparison may indicate whether a validity of the encrypted token is verified.
  • the evaluator 50 verifies whether the serial number typed in by a user is a valid serial number or an invalid serial number.
  • the evaluator may be configured to use a variable number of bits to evaluate whether the structure bits fulfill a predetermined condition - "yes" or "no". During the evaluation the evaluator may use a higher number of structure bits when the number of information bits in the decrypted token 40 is lower or it may use a lower number of structure bits in the evaluation when the number of information bits 42 is comparatively higher.
  • a evaluator 50 may be configured to evaluate a higher number of structure bits if the number of information bits is reduced and vice- versa.
  • the other bits 47 of the decrypted token 40 can be the information bits 42.
  • the evaluator 50 is configured to use at least a portion of the information bits 42 to verify a validity of the encrypted token 10.
  • the encrypted token 10 may comprise a clear bit section with the clear bits 46.
  • the decryptor 20 is configured to not decrypt the clear bits 46 and to use at least a portion of these clear bits 46 for evaluating whether a predetermined condition is fulfilled.
  • the encrypted token 10 in the decrypted token 40 can comprise different bit sections.
  • Fig. 5 for the purpose of illustration, the composition of such an encrypted token and the encrypted token is exemplarily explained.
  • an encrypted token 10 may comprise obfuscated bits, for example, 126 obfuscated bits in an encrypted section.
  • the encrypted token may comprise a clear bit section 46 with, for example, 14 clear bits. According to embodiments, a user may not be able to understand the meaning of the obfuscated bits, but the user can understand the meaning of the clear bits in the clear bit section of the encrypted token 10.
  • the encrypted token 10 may comprise a clear bit section 46, but in other embodiments, it does not comprise a clear bit section and all of the bits are obfuscated bits in the encrypted section.
  • the decryptor 20 decrypts the encrypted token by means of a decryption key in order to obtain a decrypted token 40.
  • the decrypted token 40 may comprise more bits, for example, 158 bits compared to the encrypted token 10, which comprises in this example only 140 bits. This number may, again, include the 14 clear bits of the clear bit section 46.
  • the decrypted token 40 may also be named plain token 40. In this embodiment, apart from the 14 clear bits, the plain token 40 comprises 144 plain bits.
  • the plain bits may include information concerning , for example, access rights to certain features of a product. These information in the plain bits are visible for a user, but in contrast, this information is not visible - this means encrypted- for a user in the obfuscated bits.
  • the encrypted token is encrypted with the secret key and, as will be described below, decrypted with a public key of a cryptosystem.
  • This terminology may differ to a standard terminology which may make use of the terms public- key encryption and secret-key decryption.
  • the 144 plain bits exemplarily consist of 40 information bits 42, 80 structure bits 44, 6 random bits 48 and 18 trial bits 49.
  • the decrypted token 40 may furthermore comprise the above-mentioned 14 clear bits 46.
  • An evaluator 50 may now be configured to execute a validation algorithm in order to verify whether the structure bits 44 comprise the required structure. This means, that the structure bits fulfill the predetermined condition.
  • the encrypted token e.g. the serial number is valid.
  • a predetermined condition is, for example, that the first 14 bits of the structure bits 44 are a copy of the clear bits 46 and that the remaining bits of the structure bits 44 comprise a "1".
  • Information, which is included in the clear bits, can be directly read by a user from the serial number.
  • Information, which is contained in the information bits are concealed from a user if he tries to read his encrypted serial number.
  • the structure bits 44 determine whether a decrypted token is valid or not.
  • the random bits 48 and the trial bits 49 serve to find a user specific token, which is encryptable with a private key.
  • the plain token comprises random bits and trial bits.
  • the plain token with the bit length 60 cannot comprise more than 50 bit information, since the plain token can be unambiguously calculated from the encrypted token with 50 bits.
  • the 10 trial bits can be used to find an encryptable plain token without reducing the number of possible information bits.
  • the random bits, which are also used to find an encryptable plain token are taken from the possible information bits. That means that the random bits reduce the number of information bits and the trial bits do not reduce the number of information bits in a plain token.
  • the random bits 48 and the trial bits 49 may be used to find a plain token, which can be encrypted with an encryption key, e.g. a private key of a Niederreiter-algorithm. Details for the encrypting of a plain token will be discussed later therein, but it should be noted that according to another embodiment of the invention, the apparatus 100 may comprise an evaluator 50, which is configured to use at least a portion of the random bits 48 of the decrypted token 40 for evaluating the validity of the encrypted token 10. This means that referring to Fig. 4, the other bits 47 may comprise beside information bits 42 random bits 48. It should be noted that the number of bits shown in Fig.
  • a decryptor 20 of an apparatus 100 is configured to decrypt an encrypted token 10 using a decryption key to obtain a decrypted token 40 in which the decrypted token 40 comprises less than or equal to 200 bits, hi this embodiment the number of information bits is less than or equal to 100 bits and the number of the structure bits of the decrypted token is less than or equal to 100 bits.
  • the decryptor 20 is configured for performing a decryption having block lengths equal to or less than 200 bits and in which the evaluator 50 is configured for performing an operation of comparison with a predetermined condition using a number width of equal to or less than 100 bits.
  • the apparatus 200 comprises a plain token generator 150 for generating a plain token 40, wherein the plain token generator 150 is configured to generate a plain token 40 having information bits related to the product. Furthermore, the plain token generator 150 is configured to generate a plain token 40 having structure bits related to a predetermined condition for verifying a validity of the encrypted token 10. The plain token generator may be configured to generate structure bits 44, which fulfill a predetermined condition.
  • the apparatus 200 may furthermore comprise an encryptor 120 for encrypting the plain token 40 using an encryption key 130 in order to obtain an encrypted token 10.
  • the encryptor 120 may be configured to perform an encryption of a plain token 40 using a public key cryptographic method.
  • the encryption key 130 which is used by the encryptor 120 to generate an encrypted token, may, for example, be a private key.
  • the encryptor 120 may be configured to generate an encrypted token 10 having fewer bits than the plain token 40. According to some embodiments, this may be possible by the usage of mapping bits, for example, the random bits 48 and/or the trial bits 49.
  • the encryptor 120 may be configured to apply a certain encryption algorithm, for example, the Niederreiter algorithm.
  • the encryptor may perform any public/private key method in order to obtain an encrypted token.
  • the Niederreiter cryptosystem will be explained in more detail.
  • a bit vector, which comprises a length n with a weight t is a bit vector that contains n bits, wherein exactly t bits comprise the value "1" and n-t bits the value "0", for example, comprises the bit vector 0110 0101 1011, the length 12 and a weight 7.
  • the message m is represented as a bit vector of the length n with:
  • Different messages can be encrypted with the encryption key (public key or private key depending on the terminology).
  • a corresponding decrypted message with 126 bits is calculated.
  • B is the above-defined number of bit vectors with the length n and the weight t.
  • a plain message is encrypted with a public key and a encrypted message is decrypted with a secret key.
  • a public key is used to decrypt the encrypted serial number and a private key or a secret key is used to encrypt the decrypted serial number.
  • a terminology with respect to some embodiments of the invention is chosen so that the decryption is performed with a public key and the encryption is performed with a secret key.
  • the plain token generator 150 may comprise a processor 152, which is configured to determine a higher number of information bits 42 when a first subset Sl of functions of a product having less, less expensive or less complicated functions to be usable by a user is generated and to determine a lower number of information bits when a second subset S2 of functions of a product having more, more expensive or more complicated functions to be usable by a user is generated.
  • the plain token generator 150 with its processor 152 may generate exemplarily a plain token for a first subset Sl, which includes only the functionalities Fl and F2 of the product 80.
  • the subset Sl comprises therewith less functions of the product.
  • the first subset may comprise less expensive or also less complicated functions.
  • the plain token generator 150 generates a plain token 40 depending on the number of functions, which shall be accessible with the generated encrypted token.
  • the processor 152 may generate a plain token 40 comprising only 8 information bits.
  • the plain token generator 150 may be configured to determine depending, for example, on the number of the retail price of the product or the complexity of the functions of the product, which shall be accessible by the encrypted token, the number of information bits within the plain token 40.
  • the apparatus 200 comprises a plain token generator 150, which is configured for determining a number of structure bits based on an intended retail price of the product, wherein the plain token generator 150 is configured to generate a higher number of structure bits for a higher retail price and a comparatively lower number of structure bits for a comparatively lower retail price. As it is schematically shown in Fig.
  • the plain token generator 150 may also be configured to generate a plain token, which additionally comprises a clear bit section 46 and a section 40 to be encrypted.
  • the clear bit section may comprise information on the product, wherein the information is not related to a level of product access, as described above.
  • the information bits 42 of the section 40 to be encrypted may be related to the level of product access.
  • the encryptor 120 is configured for only encrypting the section 40 to be encrypted and to not encrypt the clear bit section 46.
  • the final encrypted token comprises an encrypted section and a clear bit section 46, which can be read by a user.
  • the generated encrypted token may be a serial number, which is sold together with the software product to a customer or user.
  • This serial number may comprise a clear bit section so that a user can understand and read this section being part of the serial number and which may be related to the software product.
  • the plain token generator 150 may furthermore be configured for generating at least one trial bit 49 in addition to the information bits 42 and the structure bits 44, wherein the structure bits do not depend on a bit value of the at least one trial bits 49.
  • the encryptor 120 can be configured for performing an encryption operation of the plain token 40, which results in a number of bits of the encrypted token 10, which is smaller than a number of bits of the plain token 40.
  • the encryptor 120 may be configured to determine whether an encrypted token 10 exists for a first value of the at least one structure bit and to determine whether an encrypted token exists for a second value of the at least one trial bit when an encrypted token does not exist for the first value of the at least one trial bit. Since, for certain cryptosystems the number of bits of the encrypted token is smaller than the number of bits of the plain token, not every plain token can be encrypted. For the encryption, a certain cryptosystem algorithm may be used, for example, the Niederreiter algorithm. Therefore, the encryptor may be configured to accurately test or check if an encrypted token according to the encryption algorithm exists for a first bit structure or bit combination of the structure bits in the plain token 40.
  • the encrypted token is generated and if an encrypted token does not exist for the chosen bit structure of the structure bits, a second bit structure or value of the at least one structure bit is proven. This is repeated until an encrypted token is generated.
  • mapping bits also named herein mapping bits, which may also be part of the plain token 40
  • the probability to find an encrypted token may be r ⁇ 1 - 8.55 x 10 "21 . This means that the probability is almost 1.
  • a plain token 40 may comprise structure bits 44.
  • the generation of an encrypted token should be performed so that a user of a valid encrypted token cannot or hardly determine a further value encrypted token. Furthermore, if a user succeeds to discover or hack the evaluation algorithm and the respective decryption key, it should be impossible for the user to determine from the evaluation algorithm and the respective decryption key the generation algorithm for other valid encrypted tokens.
  • a user for example, with a valid serial number for a software product, should not be able to determine a further different valid serial number for the software product.
  • a user who discovers the validation algorithm on the software product should not be able to determine the generation algorithm from the algorithm and the respective applied decryption key.
  • An evaluation algorithm which is performed by an evaluator, may be implemented in the application, for example, the software product, which is used by a user. It might be possible that a software pirate or hacker determines the evaluation algorithm by reverse engineering. This should be prevented and therefore the encrypted token may be encrypted so that the change of just one bit of the encrypted token results in a change of more and other bits of the plain token during the decryption process.
  • the generation algorithm for an encrypted token is not delivered together with the product and is not accessible by a user. Therefore, a user does normally not know the generation algorithm for encrypting a plain token and which is performed by the encryptor 120.
  • the structure bits 44 of the plain token may be related to a level of security of the product and may be chosen to prevent a encrypted serial number to be hacked.
  • a so-called Brute-force attack a user tries randomly chosen serial numbers until a serial number is accepted by the application, e.g. the software product, to be valid.
  • a plain token or decrypted serial number comprises S structure bits, only a single serial number of 2 s randomly chosen serial numbers is valid. This means only one combination among the 2 possible values of the structure bits deliver a valid serial number.
  • an encrypted serial number 10 may comprise 140 bits, including 14 clear bits 46.
  • the encryptor 120 of the apparatus 200 may be configured to perform this transformation using a Niederreiter encryption algorithm.
  • the above-mentioned trial bits 49 are used for the encryption.
  • the above-mentioned 18 trial bits can have 2 18 different bit combinations or values. As a consequence, 2 different decrypted serial numbers are available for a given number of clear bits, information bits and structure bits.
  • the encryptor 120 can be configured to test or check if a decrypted serial number (plain token) among these 2 18 bit combinations can be encrypted by means of a private key.
  • the encryptor 120 may be configured to apply the Niederreiter encryption by means of a private key only on the information bits, structure bits and trial bits. The Niederreiter encryption is not applied to the clear bits.
  • the probability p that one decrypted serial number or plain token can be encrypted by means of the encryption key 130, e.g. the private key, is:
  • the encryptor 120 should be configured to encrypt normally every plain token or decrypted serial number by means of the used encryption or generation algorithm. Therefore according to some embodiments of the invention 6 bits from the 46 information bits do not comprise any information related to the product. These 6 bits are used as random bits 48, which are schematically shown in the plain token in Fig. 5 section C. These random bits 48 are used to increase the number of possible bit combinations to encrypt a decrypted serial number. These increased number of bit combinations are then tested by the encryptor 120 whether they can be encrypted by means of the private key or not.
  • the probability that the encryptor 120 can perform an encryption of the plain token is 1 or almost 1. In other words, if a certain number of information bits is not used for carrying information, but for providing additional sufficient bit combinations, which are checked by the encryptor whether the plain token can be encrypted with the private key, every plain token or almost every plain token can be encrypted by the encryptor 120.
  • Every decrypted serial number, which is generated or determined by the plain token generator 150, can, according to some embodiments, be encrypted by the encryptor 120 so that an encrypted serial number can be generated to each decrypted serial number, an encrypted serial number can be generated.
  • This encrypted serial number can then be sold together with a software product to a customer or user.
  • the apparatus 200 may be configured to generate encrypted tokens 10 with a different security level. This means that the apparatus 200 may be configured to provide encrypted tokens 10 with a scalable security.
  • the number of structure bits 44 and information bits 42 can vary depending on a desired level of security, as schematically depicted by the arrow 111 in Fig. 7. If the number of structure bits is increased the number of information bits in the plain token may be reduced and vice versa.
  • the encrypted token or the encrypted serial number can be adapted to a desired security level depending on the user or on the product.
  • all bits that are not required for encoding the payload can be used for increasing the level of security of the encoded token.
  • the apparatus 200 can be configured so that the generated encrypted token, which is associated to a product, can comprise a tailored security level.
  • a high level of security may be given if the encrypted token comprises 140 bits including 14 clear bits and 126 obfuscated bits.
  • the corresponding plain token may comprise 158 bits with 14 clear bits, 40 information bits 80 structure bits, 6 random bits and 18 trial bits.
  • the encrypted token may comprise 140 bits with 14 clear bits and 120 obfuscated bits.
  • the corresponding plain token may comprise 158 bits with 14 clear bits, 60 information bits, 60 structure bits, 6 random bits and 18 trial bits.
  • bit length of a encrypted token predetermined and the number of information bits and structure bits is constant. This means that the more structure bits used, the higher the level of security is, but as a consequence, less information bits are available for information related to the product.
  • Fig. 8 a further embodiment of the invention related to an apparatus 200 and the method for generating an encrypted token associated to a product is illustrated. In this embodiment, an encrypted serial number for a software product is generated.
  • the plain user specific token 40 comprises in this example 4 clear bits 46, 10 information bits 42, 6 structure bits 44, 2 random bits 48 and 2 trial bits 49.
  • the plain token generator 150 (see Fig. 6) may be configured to generate the above-mentioned decrypted serial number.
  • the 4 clear bits 46 may contain, for example, a software version number, e.g. version 7, which is indicated to a user as binary number (see row 2).
  • the first bit of the information bits 42 indicates whether a user can play a Blu-Ray disc or not.
  • the second bit of the information bits 42 determines whether a user may burn a Blu-Ray disc.
  • the software product may comprise an ID, for example, an ID 32.
  • the respective bit combination is created by the plain token generator and is written on the remaining information bits, as it is shown in row 4 of Fig. 8.
  • the structure bits 44 determine whether a plain user specific token is valid if the decrypted token is checked later on by the evaluator 50.
  • the structure bits 44 may comprise a bit structure, which is verified by the evaluator later on and compared to the predetermined condition.
  • the plain user specific token may be valid if the structure bits comprise a copy of the clear bits 46 and a copy of the random bits 48. This means that the structure bits may comprise random bits, which are used later on in order to be able to encrypt the plain token, i.e. to find an encrypted token.
  • the plain user specific token may furthermore comprise a bit structure as depicted in row 5 of Fig. 8, wherein the random bits A 5 B are copied to the structure bits, wherein each of the bits A and B can be a "1" or a "0". Therefore the 2 trial bits 49 and the 2 random bits 48 can have 16 possible bit combinations. These 16 possible bit combinations for the trial and random bits are shown in the rows 6 to 21.
  • one value or plain token is needed, which can be encrypted with an encryption key, for example, with a private key of a cryptosystem.
  • a respective generation algorithm for generating an encrypted token may be based on a Niederreiter cryptosystem.
  • Exemplarily the bit structure of the plain token in row 16 may be encryptable.
  • the result of the encryption by the encryptor 120 is exemplarily depicted.
  • the clear bits 46 are not encrypted and they are identical to the clear bits 46 of the plain token 40.
  • the encrypted token 10 comprises together with the clear bits 46 a bit length of 22 bits, which is smaller compared to the bit length of 24 bits of the plain token 40 including the clear bits 46.
  • the encrypted token 10 together with the clear bits 46 comprises a smaller number of bits than the corresponding plain token with clear bits.
  • the plain token 10 may comprise an identical number of bits than the corresponding encrypted token.
  • the encrypted token may comprise more bits than the corresponding plain token.
  • the number of clear bits added to the plain token may be the same number of clear bits 46, which comprises the corresponding encrypted token.
  • a user of the software product can now enter the encrypted user specific token at his computer in order to work with the software product.
  • the encrypted token 10 which is exemplarily depicted in row 22 in Fig. 8 as a binary number may be entered by a user as a numeral and letter code. This means that the binary number may be encoded so that a serial number comprises numerals and letters, for example, IKS3-K9U7-KL64-98JH.
  • FIG. 9 an embodiment of a method for verifying a validity of an encrypted token associated to a product is shown in a flow chart.
  • the method may comprise a step of decrypting 300 an encrypted token to obtain a decrypted token having information bits and structure bits.
  • the method further comprises a step of evaluating 310 whether the structure bits fulfill a predetermined condition, wherein the encrypted token is verified to be valid when the predetermined condition is fulfilled or is not verified to be valid when the predetermined condition is not fulfilled.
  • the step of decrypting may be performed by applying a public/private key cryptosystem algorithm to a encrypted token.
  • the decrypting 300 may be performed by applying an public/private key method, e.g. a RSA-algorithm, a McEliece algorithm or a Niederreiter-algorithm to an encrypted token to obtain a decrypted token having information bits related to the product and structure bits.
  • an public/private key method e.g. a RSA-algorithm, a McEliece algorithm or a Niederreiter-algorithm
  • the step of decrypting 300 an encrypted token may be performed so that the decrypted token comprises a larger number of bits than the encrypted token.
  • the step of decrypting 300 may be performed so that a clear bit section of the encrypted token is not changed.
  • Evaluating 310 may be performed by comparing the structure bits with a predetermined bit structure of a predetermined condition. Furthermore the evaluating 310 may include to compare a variable number of bits of the decrypted token with a predetermined condition or predetermined bit structure. The number of structure bits may vary depending on a desired level of security for the encrypted token. Therefore the evaluating may be performed with a varying number of structure bits.
  • the step of evaluating 310 may be performed so that the structure bits or a value derived from the structure bits to other bits included in the decrypted token or a value derived from the other bits included in the decrypted token are compared with a predetermined bit structure of the predetermined condition.
  • the method for verifying a validity of an encrypted token may furthermore comprise a step of determining a level of product access in accordance with the information bits when the encrypted token is verified to be valid.
  • the method for verifying a validity of an encrypted token associated to a product can be performed by a computer program.
  • the inventive method can be a computer program having a program code for performing at least one of the inventive methods when the computer program runs on a computer.
  • FIG. 1 through 8 are illustrated as block diagrams of an apparatus. These Figs, simultaneously are illustrations of a method where the block functionalities correspond to the method steps.
  • FIG. 10 an embodiment of a flow chart of the method for generating an encrypted token associated to a product is depicted.
  • the method comprises a step of generating 400 a plain token having information bits related to the product and having structure bits related to a predetermined condition for verifying a validity of the encrypted token, wherein the structure bits fulfill the predetermined condition.
  • the method further comprises a step of encrypting 410 the plain token by a means of an encryption key to obtain an encrypted token.
  • the generation 400 of a plain token having information bits and structure bits related to a predetermined condition may be performed by means of a plain token generator as described therein and the encrypting 410 may be performed by a means of an encryptor 120 as described herein.
  • the step of encrypting may be performed by the usage of a public/private cryptosystem in order to encrypt the plain token by means of an encryption key.
  • the step of encrypting 410 may be performed using a private key of a public/private cryptosystem, for example, a private key of a RSA- algorithm, McEliece- algorithm or Niederreiter-algorithm.
  • the encrypting 410 may be performed so that the encrypted token comprises a tailored level of security.
  • the security level may depend, for example, on a retail price of the product which is accessible with the encrypted token.
  • the generation 400 of a plain token and the encrypting 410 may be performed so that the encrypted token comprises information concerning a product access. And as described above encrypting 410 may be performed so that an encrypted token comprises fewer bits than the plain token.
  • the method for generating an encrypted token associated to a product can be performed by a computer program.
  • the inventive method can be a computer program having a program code for performing at least one of the inventive methods when the computer program runs on a computer.
  • a flow chart of an embodiment of the method for generating an encrypted token associated to a product is depicted.
  • a plain user specific token is generated in a first step.
  • the clear bits and the information bits of the plain user specific token are chosen and fixed in step 2.
  • the clear bits can comprise, for example, information regarding a software version number and the information bits may comprise information regarding a product access, e.g. an access of certain product functionalities. Both clear and information bits contain information. However, information bits will be encrypted in the encrypted token and clear bits will not. Hence, the clear bits in the plain and in the encrypted token are identical and the user may be able to see the information that the clear bits contain. By contrast, the information of the information bits in an encrypted token is hidden to the user.
  • step 3 in Fig. 11 random bits are chosen in order to increase the probability to be able to perform an encryption of the plain user specific token. By choosing the number of random bits large enough, the probability of failing to be able to generate an encrypted token is negligible. Depending on the number of random bits, which are taken, one can scale the probability of failure to encrypt a plain token. The probability of failing to encrypt a plain token may also be affected by the number of trial bits. If all random bits of a plain token have been tested, the generation method for generating an encrypted token may fail. This is schematically shown in step 3 a. If all random bits of a plain token are tested and no success for encrypting the plain token is achieved by means of the encryption algorithm, a failure may occur.
  • the structure bits are calculated in step 4 in Fig. 11.
  • the structure bits are needed for the evaluation of the encrypted token.
  • a user of an application e.g. a software product enters the encrypted token to the application.
  • the application decrypts the token, obtains the plain token or decrypted token and checks whether the encrypted token is genuine. For this check, the structure bits are used. Only for a specific combination of structure bits, the plain token passes the check.
  • the structure bits can be a hash value, e.g. a hash value of the other bits of the plain token, but it is also possible that the structure bits are just a copy of the clear bits with some additional fixed pattern bits or other bit combinations.
  • the structure bits may depend on random bits being part of the decrypted token.
  • step 5 for each trial bit combination in the plain token, it is tested whether a corresponding encrypted user specific token 10 can be encrypted. Any combination of trial bits should be tested. This means for K trial bits, the loop of step 5 in Fig. 11 will be executed 2 k times if the plain token cannot be encrypted.
  • a public key encryption of the cryptosystem can be used.
  • a secret or private key of a cryptosystem to decrypt (in the sense of the cryptosystem) the plain token in order to obtain the encrypted token (encrypted in the sense of the user) is used. If the secret key decryption of the cryptosystem succeeds, this means that it can calculate a corresponding encrypted token 10, the generation method does terminate with success.
  • the public/secret key method is chosen such that the operands of the public key and the secret key have the same number of bits, then the generation method consists only of steps 1 , 2 and 4. This means that the plain token may not comprise random bits or trial bits.
  • Embodiments of the invention pertain to the domain of public key cryptography and digital signatures. It is used to achieve a maximum level of security by utilizing unused bits of the payload of a user specific digitally signed token. Other embodiments further relate to a scenario where the total length of a secure user specific token is limited due to external influences or specific properties of the domain within which it is used.
  • An application may decrypt the encrypted user specific token in order to obtain the plain user specific token or the decrypted token.
  • the public/secret key method can be used to encrypt a plain token or to decrypt an encrypted token. The public/secret key method can be used such that the plain user specific token contains more total bits than the secure user specific token.
  • an apparatus for generating a user specific token or encrypted token with a scalable security may perform an encryption of the plain token by means of algorithm related to a retail price, a number of functions or the complexity of a function of the product.
  • the plain user specific token consists of clear bits, structure bits, information bits, random bits and trial bits.
  • a secure user specific token or encrypted token may consist of clear bits and encrypted bits, hi some embodiments, the difference of the bit-count between the plain and the encrypted user specific token can be equal to the number of trial bits. This means that the number of trial bits may depend on the difference of the bit-count of the plain token or decrypted token and the encrypted token. According to an preferred embodiment the number of trial bits can be defined as the difference of the bit-count of the plain token or decrypted token and the encrypted token.
  • an apparatus 200 for generating an encrypted token may be configured to generate an encrypted token with scalable security.
  • the generation method has scalable security with different security levels against, for example, Brute force attacks, when a user tries randomly different encrypted tokens.
  • Brute force attacks when a user tries randomly different encrypted tokens.
  • the Brute force attack may succeed.
  • about 80 bits are sufficient to achieve a cryptographic security. The more number of structure bits chosen, the less number of information bits are available, and conversely.
  • the parameters of a cryptosystem which is used for decrypting an encrypted token and for encrypting a plain token, can be chosen more secure and less secure.
  • the user does not usually want to enter a lot of characters, but this may mean that the bit size of the operands (tokens) of the cryptosystem has to be chosen relatively small.
  • the used crypto algorithm may be less secure.
  • the choice of the cryptosystem used for encrypting and decrypting influences the security of the generated encrypted token, hi a preferred embodiment, the public key cryptographic system used for implementation is the Niederreiter cryptosystem.
  • a serial number being a user specific token is used to authorize access to a customer's software.
  • the security of the serial numbers is chosen such that the serial number is generally small enough for an end user to type it on a keyboard while it is secure enough to be hard to be hacked.
  • the structure of the plain token, e.g. the decrypted serial number is flexible in allowing product customization on a logic level such that the more expensive customization due to technology cost the harder the serial number will be to counterfeit. This is accomplished by identifying expensive product configurations with the least number of payload bits, while identifying a "cheap" product configuration with a maximum number of payload bits.
  • public key cryptography is used to encrypt the user specific token.
  • all bits that are not required for encoding a payload, i.e. the key information are used to increase the security.
  • the invention is an enhancement of existing public/secret key cryptography systems, like, for example, the Niederreiter cryptosystem.
  • expensive products can be sold with tokens having a high security level and cheaper products with tokens having a lower security level. This is because typical serial numbers for cheaper products (OEM products) carry more information describing customization options.
  • the secure user specific token contains information that is directly visible to the user, this means a user can see whether he has a serial number for one version or for a different other version of a product.
  • an apparatus which is part of the product or the application, decrypts an encrypted user specific token with the public key and the plain user specific token is obtained.
  • the invention provides an algorithm for generating secure user specific tokens or user access keys that are very hard to counterfeit and which provide encrypted user specific tokens with a high security level for expensive products and a lower security level for cheaper products.
  • an apparatus for generating an encryptor token can be used to create the secure user specific token with a maximum level of security.
  • a system and a method for verifying a validity of an encrypted token can create a user specific token with a maximum level of security.
  • a system and method to create a secure user specific token with a maximum level of security wherein said user specific token consists of clear bits, structure bits, information bits, random bits, and trial bits.
  • a system and method to create a secure user specific token with a maximum level of security wherein said token contains less total bits than the corresponding insecure representation.
  • a system and method to create a user specific token with a maximum level of security wherein said user specific token consists of clear bits, structure bits, information bits, random bits, and trial bits and contains less total bits than the corresponding insecure representation.
  • a system and method to validate a user specific token with a maximum level of security A system and method to validate a user specific token with a maximum level of security, wherein consists of clear bits, structure bits, information bits, random bits, and trial bits. A system and method to validate a user specific token with a maximum level of security, wherein said token contains less total bits than the corresponding insecure representation. A system and method to verify a user specific token with a maximum level of security, wherein said token consists of clear bits, structure bits, information bits, random bits, and trial bits and contains less total bits than the corresponding insecure representation. A secure representation of a user specific token with a maximum level of security.
  • a secure representation of a user specific token with a maximum level of security that consists of clear bits, structure bits information bits, random bits and trail bits.
  • a secure representation of a user specific token with a maximum level of security that consists of clear bits, structure bits information bits, random bits and trail bits and contains less total bits than the corresponding insecure representation.
  • FIGs. 1 though 8 are illustrated as block diagrams of an apparatus. These Figs, simultaneously are illustrations of a method where the block functionalities correspond to the method steps.
  • the inventive methods can be implemented in hardware or in software.
  • the implementation can be performed using a digital storage medium, in particular, a disc, a DVD or a CD having electronically-readable control signals stored thereon, which co-operate with programmable computer systems such that the inventive methods are performed.
  • the present invention is therefore a computer program product with a program code stored on a machine-readable carrier, the program code being operated for performing the inventive method when the computer program runs on a computer.
  • the inventive methods can, therefore, be a computer program having a program code for performing at least one of the inventive methods when the computer program runs on a computer.

Abstract

Des modes de réalisation de l'invention portent sur un appareil servant à vérifier une validité d'un jeton crypté associé à un produit, l'appareil comprenant un décrypteur pour décrypter un jeton crypté à l'aide d'une clé de décryptage afin d'obtenir un jeton décrypté comprenant des bits d'informations relatifs au produit et des bits de structure. L'appareil comprend en outre un évaluateur pour évaluer si les bits de structure satisfont une condition prédéterminée, le jeton crypté étant vérifié comme étant valide lorsque la condition prédéterminée est satisfaite ou n'étant pas vérifié comme étant valide lorsque la condition prédéterminée n'est pas satisfaite. D'autres modes de réalisation portent sur un appareil pour générer un jeton crypté associé à un produit, l'appareil comprenant un générateur de jetons simples et un crypteur pour crypter le jeton simple à l'aide d'une clé de cryptage afin d'obtenir un jeton crypté.
PCT/EP2009/006295 2008-11-21 2009-08-31 Appareil de vérification et de génération d'un jeton crypté et procédés pour celui-ci WO2010057546A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP09778224A EP2353251B1 (fr) 2008-11-21 2009-08-31 Appareil de vérification et de génération d'un jeton crypté et procédés pour celui-ci
US13/112,367 US8719583B2 (en) 2008-11-21 2011-05-20 Apparatus for verifying and for generating an encrypted token and methods for same
US14/269,046 US9043606B2 (en) 2008-11-21 2014-05-02 Apparatus for verifying and for generating an encrypted token and methods for same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11674108P 2008-11-21 2008-11-21
US61/116,741 2008-11-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/112,367 Continuation US8719583B2 (en) 2008-11-21 2011-05-20 Apparatus for verifying and for generating an encrypted token and methods for same

Publications (1)

Publication Number Publication Date
WO2010057546A1 true WO2010057546A1 (fr) 2010-05-27

Family

ID=41396293

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/006295 WO2010057546A1 (fr) 2008-11-21 2009-08-31 Appareil de vérification et de génération d'un jeton crypté et procédés pour celui-ci

Country Status (3)

Country Link
US (2) US8719583B2 (fr)
EP (1) EP2353251B1 (fr)
WO (1) WO2010057546A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8452965B1 (en) * 2010-06-29 2013-05-28 Emc Corporation Self-identification of tokens
US8655787B1 (en) 2010-06-29 2014-02-18 Emc Corporation Automated detection of defined input values and transformation to tokens

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6735253B1 (en) 1997-05-16 2004-05-11 The Trustees Of Columbia University In The City Of New York Methods and architecture for indexing and editing compressed video over the world wide web
WO2006096612A2 (fr) 2005-03-04 2006-09-14 The Trustees Of Columbia University In The City Of New York Systeme et procede d'estimation du mouvement et de decision de mode destines a un decodeur h.264 de faible complexite
WO2009126785A2 (fr) 2008-04-10 2009-10-15 The Trustees Of Columbia University In The City Of New York Systèmes et procédés permettant de reconstruire archéologiquement des images
US20120239566A1 (en) * 2009-09-17 2012-09-20 Royal Canadian Mint/Monnaie Royale Canadienne Asset storage and transfer system for electronic purses
US9009149B2 (en) * 2011-12-06 2015-04-14 The Trustees Of Columbia University In The City Of New York Systems and methods for mobile search using Bag of Hash Bits and boundary reranking
EP2683127A1 (fr) * 2012-07-05 2014-01-08 Alcatel-Lucent Autorisation de bon pour serveur en nuage
TWI613971B (zh) * 2016-09-01 2018-02-11 新唐科技股份有限公司 電子霧化器防偽裝置、系統及其防偽方法
US10382203B1 (en) * 2016-11-22 2019-08-13 Amazon Technologies, Inc. Associating applications with Internet-of-things (IoT) devices using three-way handshake
US10223541B2 (en) * 2017-01-24 2019-03-05 Salesforce.Com, Inc. Adaptive permission token
US11687929B2 (en) * 2018-03-23 2023-06-27 American Express Travel Related Services Co., Inc. Authenticated secure online and offline transactions
US10652022B1 (en) 2019-10-10 2020-05-12 Oasis Medical, Inc. Secure digital information infrastructure
US10979228B1 (en) 2019-10-10 2021-04-13 Oasis Medical, Inc. Secure digital information infrastructure
US11470085B2 (en) * 2020-06-16 2022-10-11 At&T Intellectual Property I, L.P. Service and security enhancement of communication services
IT202100025925A1 (it) * 2021-10-08 2023-04-08 Phoenix ICT Metodo e sistema anti ddos per la gestione dinamica di una risorsa attiva
US20230388793A1 (en) * 2022-05-27 2023-11-30 Icashe, Inc. Secure mobile transaction apparatus and method

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020162000A1 (en) * 1999-05-22 2002-10-31 Hartwig Benzler Method for the verification of the integrity and authorship of a text
US20030149670A1 (en) 2002-02-05 2003-08-07 Cronce Paul A. Method and system for delivery of secure software license information
US20050010788A1 (en) * 2003-06-19 2005-01-13 International Business Machines Corporation System and method for authenticating software using protected master key

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9011700D0 (en) * 1990-05-25 1990-07-18 Inmos Ltd Communication interface
US6963859B2 (en) * 1994-11-23 2005-11-08 Contentguard Holdings, Inc. Content rendering repository
US6754820B1 (en) * 2001-01-30 2004-06-22 Tecsec, Inc. Multiple level access system
US7570781B2 (en) * 1999-05-19 2009-08-04 Digimarc Corporation Embedded data in gaming objects for authentication and association of behavior information
US6973576B2 (en) * 2000-12-27 2005-12-06 Margent Development, Llc Digital content security system
US7305548B2 (en) * 2001-10-22 2007-12-04 Microsoft Corporation Using atomic messaging to increase the security of transferring data across a network
US7822685B1 (en) * 2003-04-09 2010-10-26 Cisco Technology, Inc. Method and system for digital rights management brokering and digital asset security transcoding
US7487537B2 (en) * 2003-10-14 2009-02-03 International Business Machines Corporation Method and apparatus for pervasive authentication domains
US7673148B2 (en) * 2004-10-15 2010-03-02 Microsoft Corporation Versioning component for applications
US20090327139A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Loosely coupled hosted application system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020162000A1 (en) * 1999-05-22 2002-10-31 Hartwig Benzler Method for the verification of the integrity and authorship of a text
US20030149670A1 (en) 2002-02-05 2003-08-07 Cronce Paul A. Method and system for delivery of secure software license information
US20050010788A1 (en) * 2003-06-19 2005-01-13 International Business Machines Corporation System and method for authenticating software using protected master key

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NICOLAS T COURTOIS ET AL: "How to Achieve a McEliece-Based Digital Signature Scheme", ADVANCES IN CRYPTOLOGY ASIACRYPT 2001; 7TH INTERNATIONAL CONFERENCE ON THE THEORY AND APPLICATION OF CRYPTOLOGY AND INFORMATION SECURITY GOLD COAST, AUSTRALIA, DECEMBER 9 13, 2001 PROCEEDINGS (BOOK SERIES: LECTURE NOTES IN COMPUTER SCIENCE), SPRINGER, vol. 2248, 9 December 2001 (2001-12-09), pages 157 - 174, XP007910981, ISBN: 978-3-540-42987-6, [retrieved on 20010101] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8452965B1 (en) * 2010-06-29 2013-05-28 Emc Corporation Self-identification of tokens
US8655787B1 (en) 2010-06-29 2014-02-18 Emc Corporation Automated detection of defined input values and transformation to tokens

Also Published As

Publication number Publication date
EP2353251A1 (fr) 2011-08-10
EP2353251B1 (fr) 2012-10-17
US9043606B2 (en) 2015-05-26
US8719583B2 (en) 2014-05-06
US20110283111A1 (en) 2011-11-17
US20140245022A1 (en) 2014-08-28

Similar Documents

Publication Publication Date Title
US9043606B2 (en) Apparatus for verifying and for generating an encrypted token and methods for same
US9847880B2 (en) Techniques for ensuring authentication and integrity of communications
KR101010040B1 (ko) 파일의 암호화·복호화 방법, 장치, 프로그램 및 이프로그램을 기록한 컴퓨터 판독 가능한 기록 매체
US8984293B2 (en) Secure software product identifier for product validation and activation
CN102419804B (zh) 具有冗余安全性的可靠的软件产品验证和激活
KR100702499B1 (ko) 메시지 무결성 보증 시스템, 방법 및 기록 매체
US20140223580A1 (en) Method of and apparatus for processing software using hash function to secure software, and computer-readable medium storing executable instructions for performing the method
US8392723B2 (en) Information processing apparatus and computer readable medium for preventing unauthorized operation of a program
EP3379769A1 (fr) Procédé de signature rsa ou de déchiffrement protégé au moyen d'une decomposition multiplicative d'un exposant asymétrique
KR20080050934A (ko) 조건부 인증 코드 삽입 방법 및 그 장치, 인증을 통한조건부 데이터 사용 방법 및 그 장치
US20080000971A1 (en) Method for customizing customer identifier
KR20100031106A (ko) 데이터 보안
EP3455763B1 (fr) Gestion de droits numériques destinée au partage de contenu numérique anonyme
JP5060372B2 (ja) データ処理装置
CN107278357B (zh) 密码系统和方法
JP5171787B2 (ja) サインクリプションシステムおよびサインクリプション生成方法
JP2004297755A (ja) 暗号システムにおける鍵管理サーバおよび復号装置を制御するプログラム,ならびに署名/検証システムにおける鍵管理サーバおよび検証装置を制御するプログラム
KR101188659B1 (ko) 플레이어 및 카트리지 간의 디지털 콘텐츠 보호 방법
JP4604523B2 (ja) データの移管方法およびデータの保管装置
Norberg et al. Cryptography
CN116680710A (zh) 一种密码机密钥认证方法及系统
JP5268413B2 (ja) 開示制限処理装置及びデータ処理システム及びプログラム
CN116881865A (zh) 一种许可证生成方法以及系统
JP2013197810A (ja) 暗号処理装置
JP2005269587A (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: 09778224

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2009778224

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE