Patent Application
20080164976
The present invention relates generally to radio frequency identification (RFID) tags and RFID authentication systems, and has particular utility in signing and authenticating RFID tags.
Traditionally, objects such as inventory and commercial products have been given an associated identifier to allow the object to be tracked, identified and/or monitored. Recently, barcodes are becoming displaced by radio frequency identification (RFID) technology for providing the identifiers. RFID is beneficial as it provides an automatic identification system rather than requiring a user or machine to locate the barcode tag and then scan the barcode in a particular way.
RFID relies on the storage and remote retrieval of data using devices typically referred to as RFID tags or RFID transponders. An RFID tag is an object that can be attached to or incorporated into a product or even a living being such as an animal for the purpose of identification using radio waves. There are chip-based RFID tags that contain silicon chips and antennas and RFID tags can be either passive or active.
Passive RFID tags require no internal power source. The relatively small electrical current induced in the antenna by the incoming radio frequency signal provides enough power for the circuit in the tag to power up and transmit a response. Often, passive tags signal by backscattering the carrier signal from the reader and thus the antenna is designed to both collect power from the incoming signal and also to transmit the outbound backscatter signal. Without requiring an onboard power supply, passive RFID tags can be smaller and more cost effective to implement.
Active RFID tags have their own internal power source which is used to power any circuit resident on the tag that generates an outgoing signal. Active tags have been found to be more reliable than passive RFID tags since active tags can conduct a “session” with a reader. With an onboard power supply, an active RFID tag can transmit a higher power signal which allows them to be more effective in areas where RF signals have trouble transmitting e.g., water, and relatively long distances. The onboard power supply also requires more space and thus active RFID tags are generally larger and more expensive than passive RFID tags.
An RFID system generally comprises tags, tag readers, and supporting infrastructure. The purpose of an RFID system is to enable data to be transmitted by a mobile device (the tag), which is read and processed by an RFID reader. The amount of processing and the nature of the data is largely dependent on the application. For example, the information transmitted by the tag may provide, identification or location information, or specifics about the object to which the tag is affixed. In typical applications such as for inventory tracking, the RFID system uses small, inexpensive tags affixed to objects that are to be tracked. The tag contains a transponder with a memory that is given a unique code (e.g. product code). A signal is emitted from the reader that activates the RFID tag so that the reader can read and write data to the tag. When the RFID tag passes through the electromagnetic zone created by the emission, the tag detects the reader's activation signal. The reader decodes the data encoded in the tag's memory and the data is passed to the supporting infrastructure for its particular use.
RFID technology is becoming more popular not only for reducing the effort involved in tracking inventory and commercial products, but also for combating security issues such as the existence of counterfeit or compromised products. Such security issues have become increasingly important in the pharmaceutical industry for advancing the security of the pharmaceutical supply chain and improving patient safety. Current work includes adding a layer of authentication to pharmaceutical drugs in the supply chain, in particular using a public-key infrastructure (PKI) combined with an RFID system as discussed in the white paper entitled “Securing the Pharmaceutical Supply Chain with RFID and Public-Key Infrastructure (PKI) Technologies” by Joseph Pearson, Texas Instruments Radio Frequency Identification (TI-RFID™) Systems, RFIDPH01, June 2005.
An authenticated RFID system such as that described in the above-noted white paper allows the tag to be authenticated at one or more stages in the supply chain to ensure supply-chain integrity throughout.
The above-noted implementation requires an RFID tag that is large enough to store a relatively large signature, e.g. 1024 bit digital Rivest-Shamir-Adleman (RSA) signature, which can be prohibitively expensive. As a result, the authenticated RFID tags, when signed with an RSA signature, can only accommodate one signature without requiring a tag that may be too expensive to use. Even when only one signature is desired, a relatively large tag is still required.
The use of such relatively large RSA signatures also makes the use of multiple signatures on the same tag infeasible without increasing the tag size even further which can be even more prohibitively expensive.
It is therefore an object of the following to obviate or mitigate the above-noted disadvantages.
In one aspect, there is provided a method for managing verification keys for a plurality of RFID readers in an authenticated REID system comprising determining a set of permissions indicative of which of one or more of the plurality of REID readers have permission to authenticate one or more product types; for one or more of the plurality of readers, preparing a set of verification keys according to the set of permissions, each verification key being associated with a specific product type; and distributing each the set of verification keys to respective RFID readers.
In another aspect, there is provided a key management system for an authenticated RFID system having a plurality of RFID readers configured for determining a set of permissions indicative of which of one or more of the plurality of RFID readers has permission to read one or more product types having corresponding RFID tags; preparing a set of verification keys for each of the plurality of readers according to the permissions; and distributing the verification keys to the readers.
In yet another aspect, there is provided a computer readable medium carrying computer executable instructions for performing the method of managing verification keys.
An embodiment of the invention will now be described by way of example only with reference to the appended drawings wherein:
Referring to
The CA 12 preferably communicates with the readers 14 and the signing stations 16 over a communication channel 24 to facilitate the distribution of keys through the issuance of certificates and for log reporting as necessary. The communication channel 24 may be electronic such as a local or wide area network (secure or insecure with cryptographic safeguards) or may be implemented by distributing media such as CD-ROM disks or by deploying technicians. Therefore, it will be appreciated that the readers 14 and signing stations 16 may operate together in a network or as substantially standalone units.
In some applications, there may be little or no relationship between particular ones of the readers 14 and the signing stations 16 such that they are under the control of different parties. Therefore, each party may be required to contact and communicate with the CA 12 individually in order for the readers 14 to each be able to validate the signatures written by the signing stations. It will be appreciated that the participation of a CA 12 is only one implementation and that any other management or controlling entity could also be used as will be discussed later.
The schematic block diagram of
In one embodiment, the CA 12 generates the private keys of the readers 14 (which correspond to the respective public keys Z1-N) and provides such private keys to a manufacturer of the readers 14 in a bulk encrypted set, along with the certificates CVER1-N. This embodiment provides additional assurance of the integrity of the keys, since the CA 12 can state that the operators generating the keys did not have unencrypted access to the private keys. The provision of private keys and manufacturing of the readers 14 is discussed below in connection with
The signing stations 16 are attached to RFID readers and are capable of generating elliptic curve cryptography (ECC) signatures using a crypto module 30a and writing them to the RFID tags 20. Preferably, the signing stations 16 are not used to verify signatures from other signers 16 and thus typically do not need to access certificates from other RFID readers, both signing and verifying. The signing station 16 shown in
The readers 14 are used for verifying the signatures written to the tags 20 by the signing stations 16 and typically are not used for or capable of generating signatures. Preferably, each reader 14 has its own key pair, e.g. (z1, Z1) for reader 1. The private key z1 is used to decrypt signer certificates CSIGN1 and the public key Z1 corresponds to the private key z1 and has a corresponding certificate CVER1. The reader 14 also stores a copy of the CA certificate CCA and a list of validated public keys Wj for the various signing stations 16. The reader 14 also has a crypto module 30a that is capable of validating certificates and verifying ECC signatures.
RFID Authentication Schemes using Elliptic Curve Cryptography
A generic RFID tag 20 is shown in
An example of a 256 bit tag 20 to be used in an authenticated RFID system is shown in
It can be appreciated that an RSA signature is too large to be written to such a 256 bit tag 20 and would instead require a large tag such as a 2048 bit tag 20. It can also be appreciated that an RSA signature would also be too large for tags 20 of other sizes such as 512 bits. Also, an RSA signature can be cloned when read from a genuine tag and programmed onto another. However, since the tags 20 are unique and cannot be reprogrammed, a cloned signature will not be successfully verified. It is seen from
The writing and reading of, e.g., 1024 bit RSA signatures, to and from RFID tags 20 can create a significant bottleneck in the manufacturing process. It is therefore desirable to replace an RSA signature with a smaller one, while maintaining a similar level of security. The size of a 1024 bit RSA signature requires a relatively large RFID tag (e.g. 2048 bits) that can only accommodate one signature. To reduce such bottlenecks, to provide the possibility of including multiple signatures on the same RFID tag 20 (e.g. representing stages in the manufacturing process), and to provide the possibility of using a smaller (and thus cheaper) RFID tag 20, a signature with similar security but that is smaller in size is required. It has been recognized that an elliptic curve cryptography (ECC) signature is particularly suitable for providing these features and advantages when considering the following analysis.
ECC is implemented in an algebraic system defined on the points of an elliptic curve over a finite field and encryption schemes using ECC are based on the intractability of the discrete log problem in finite groups.
In one example, the domain parameters of such an ECC cryptosystem are a curve of the form y2=x3+dx+c and a seed point P. One correspondent in the system has a private key a, 0<a<n where n is the order of the point P and a corresponding public key QA=aP. The public key may be held in a certifying authority (CA). The following principles are also applicable in binary F2″ applications.
When compared to RSA, ECC offers the same security with smaller bit sizes. The following table taken from “Recommendation for Key Management—Part 1: General Revised”, NIST Special Publication 800-57, National Institute of Standards and Technology, May 2006, compares the bit sizes of ECC and RSA at similar security levels.
To achieve the same security level as a 1024 bit RSA signature, an elliptic curve of 160 bits or higher should be used. The examples described herein compare the use of elliptic curve Pintsov-Vanstone signature (ECPVS) scheme and the use of the elliptic curve digital signature algorithm (ECDSA), to the use of public key schemes such as RSA. It will be appreciated that other ECC schemes are applicable.
ECPVS is a digital signature scheme with message recovery, which means that pall of the message that was signed can be recovered from the signature verification process. ECPVS is specified in IEEE 1363a-2004, ISO/IEEE 9796-3, and as a draft ANSI standard. In ECPVS, a message M that is to be signed is considered to be two separate and distinct portions or sets of data H and V (e.g. M=H∥V) where H is a message or a set of data that is to be hidden in the signature and recovered during the verification process, and V is a message or set of data which is also signed but is sent in the clear (or otherwise be readily or publicly available) and used in the verification process. The message H can only be recovered by those entities that possess a particular verification key and the message V can be read by any entity, e.g. any RFID reader 14, i.e. without verifying the signature.
The ECPVS signature generation algorithm typically begins by specifying a particular characteristic for the message H that can be examined during signature verification to verify the signature. For example, one can determine if the message H has a certain amount of redundancy that is above a predetermined limit sufficient to prevent an existential forgery attack. If it is determined that the original data forming the message M contains enough redundancy then H may simply be a subset of that data. If the predetermined redundancy is not found, then H may be modified to contain artificially added redundancy such as additional zeros. It will be appreciated that having a certain amount of redundancy is only one characteristic and others may be used such as any string or set of data that can be compared to a known and expected value.
For example, 80 bits of redundancy is typically what is needed to provide the same level of security as 1024 bit RSA and should preferably be chosen as the minimum threshold when the same security or better than 1024 bit RSA is desired. However, as discussed below, the amount of redundancy used can be tailored to suit the application based on the size of tag that is desired, and the minimum security level that makes forging the signature uneconomical or which is otherwise deemed to be acceptable. The following summarizes ECPV signature generation.
First, an ephemeral key pair (k, Q) is generated, where Q=kG is a point on the elliptic curve, k is a random integer 1≦k<n, and n is the order of the group generated by the elliptic curve base point G. Next, a key k1=KDF(Q) is constructed, where KDF is a key derivation function. In general, a key derivation function is used to derive a secret key from a secret value and/or a other known information. In ECPVS, KDF takes as an input a point, Q, and possibly other information, and generates an encryption key k1. The signing entity then computes a first signature component c as c=ENCk
Next, an intermediate component h is computed as h=Hash(c∥V), where Hash is a suitable hash function, e.g. SHA1. If pretended, additional information that may be available or become available to parties verifying the signature (in other words information that the verifier needs ‘on the side’ for verification), e.g. a certificate or identifying information of the signer may be incorporated into h. The intermediate component h is then converted to an integer e. A second signature component s is then calculated using a suitable signature algorithm, such as the Schnorr algorithm, where: s=e·w+k mod n, w being a long term private key of the signing entity, namely the signing station in the examples discussed above. The resultant signature is then (c, s, V) or (s, c∥V).
The following illustrates ECPV signature verification on a signature (s, c∥V), when provided with the signing entity's genuine public key W. First, the intermediate component h is computed using the component c∥V and using the same hash function used in the signing stage and any additional information, such as the identification information of the signer, where: h=Hash(c∥V). Next, h is converted to an integer e. A representation Q′ of the ephemeral public key Q is then computed using the integer e, the public key W of the signer, the base point G, and the signature component s, e.g. as Q′=sG−eW.
Next, a decryption key k1′ is computed using the same key derivation function KDF used in the signing stage, including the same additional information, namely as k1′=KDF(Q′). A representation H′ of the hidden portion H is then recovered by decrypting the component c using the key derived above, and a complementary decryption function DEC, namely as H′=DECk
Because the message M is subdivided, it is only necessary for one portion, e.g. H to contain the requisite characteristic such as redundancy, and to be hidden. The other portion V is plaintext that has the same structure as the original message and thus can improve bandwidth efficiency. As such, for an RFID tag, the visible portion V may include any portion of data that is otherwise available to RFID readers 14. The portion H hidden in c is only available to those individuals who have the public key W of the signer, whereas the data contained in V is available to all. Although the principles described herein where a portion of data is hidden to conceal sensitive information is particularly suitable for a pharmaceutical supply chain as exemplified below, it will be appreciated that such principles are equally applicable to any RFID authentication system for any product type and in any environment where authentication and privacy or confidentiality is desired. For example, the principles below are also applicable to tracking baggage in an airport, tracking any merchandise, or for authenticating users of mobile devices utilizing RFID technology, etc.
The use of ECPVS in authenticating the RFID system 10 described herein allows part of the identifying information on the tag 20 to be kept secret from unauthorized readers whilst allowing conventional readers to read the remaining data, e.g. for regular scanning operations. This is because a certain portion of data can be hidden in the signature and any other non-sensitive information can simply remain on the tag 20 as is or included as part of the plaintext V. Also, since an ECPVS signature is smaller than a 1024 bit RSA signature, a smaller tag can be used with similar security. For example, a 512 bit tag or 256 bit tag can be used depending on the application, the level of security required and the availability of such tags as will be explained in greater detail below.
An product identification (ID) code 40 (e.g. EPCglobal code) is generally shown in
In industries such as the pharmaceutical industry, the use of variation (b) ID codes 40b have been viewed as posing a privacy issue since the code 40b reveals what the product is. Therefore an illegitimate reader could potentially discern what a customer is purchasing when within the requisite range. These privacy concerns are discussed in a Food and Drug Administration (FDA) report, “FDA Counterfeiting Drug Task Force Report: 2006 Update”, which in part recommends not revealing the NDC number on the RFID tag, the NDC number containing the information that identifies the drug.
It is therefore desirable to encrypt or hide at least the product ID 54 where a variation (b) code 40b is used so that an illegitimate reader cannot discern the product type. It has been recognized that ECPVS provides a suitable ECC signature scheme (for size and efficiency) that can also hide the product ID 54 in the signature by designating the ID code 40 as the message to be signed and having the product ID 54 designated as portion H, which is hidden and recovered during verification.
Also, using ECPVS, either variation (a) or variation (b), the entire ID code 40 can be chosen as H and the non-recoverable or visible portion V can be the UID. In a simple example, ECPVS allows a digital signature to fit within an RFID tag 20 with 256 bits of storage (see
In a practical implementation, several issues should be considered. First, if the entire ID code 40 is hidden (to be recovered during signature verification), then the readers 14 not supporting ECPVS, or not possessing the correct public key Zi, would not be able to read the ID code 40 at all. The ID code 40 itself can be divided into recoverable and non-recoverable portions (e.g. where product ID 54 is recoverable), however the redundancy of the recoverable portion may be insufficient. If the ID Code 40 is to be sub-divided, the RFID tag 20 may need to be larger if additional redundancy is required and/or other ways of adding redundancy, e.g. padding would need to be explored in order to provide adequate security.
Second, the IEEE Standard 1363a-2004 specifies that the recoverable message H be padded with at least 1 byte. If it is desirable to comply with this standard, an extra byte of storage is required. Third, if a 256 bit tag 20 is used, there may be no room to store data such as the time of signing unless some of the unused bits in the AFID are used. Finally, there may not be enough redundancy in the ID Code 40 to allow the verifier 14 to determine if the signature is valid. Some out-of-band information (e.g. visual verification with a paper label) may be required. The issue of redundancy is addressed below.
As discussed, there are two types of ID codes 40a, b. The variation (a) fields cannot be directly linked to the product. In a variation (b) code 40b, the product ID 54 directly identifies the product. It is therefore desirable to encrypt or hide at least the product ID 54, namely by making the product ID 54 at least a portion of the hidden message H.
It can be appreciated that, depending on the application, the ID code 40 may not contain enough redundancy and may require that a pattern or limit be imposed on the fields to avoid a vulnerability to signature forgery.
With the 160 bit curve and SHA-1 as the hash function, the typical rule-of-thumb is to use 80 bits of redundancy. However, since each forged signature is specific to one particular RFID tag 20, it may be adequate to use a smaller number. Moreover, it may be that the amount of computing power and/or time to forge one signature is long enough to deter a forger from attempting to forge the signature. The security level should be tailored to provide enough of a deterrent to such a forger.
To offer the same security level as a 1024 bit RSA signature, an ECPVS signature with a 160 bit curve would fit within the 256 bit structure shown in
Unless there are 80 bits of redundancy, ECPVS does not offer the same level of resistance to counterfeit signatures as 1024 bit RSA. However, since each forged signature is only applicable to one particular RFID tag 20, a reduced level of resistance may be acceptable since other signatures would not be compromised.
To implement ECPVS without padding, and where no additional fields in the RFID tag 20 can be used to increase redundancy, the inherent redundancy of the ID code 40 should be relied upon to determine if the signature is valid. This may involve imposing certain patterns or structures to the ID code 40 or using some out-of-band information such as referring to a product database. Since part of the ID code 40 is contained in the recoverable portion H, readers 14 that do not support ECPVS are not able to read the entire ID code 40.
To implement ECPVS with padding, the AFI, DSFID and user lock (U) bits may be used to increase the redundancy of the recoverable message H. For example, as can be appreciated from
Although the ideal level of padding is 80 bits, a lesser number of bits may be used if for the particular application such lesser padding is secure enough to make the forgery of signatures uneconomical.
With the extra padding, if may not be necessary to rely on the inherent redundancy in the ID code 40. Therefore, the entire code 40, with the exception of the Product ID 54, can be stored as the non-recoverable message V. All readers 14 will be able to read the ID code 40, but only readers 14 with the correct public key can recover the Product ID 54.
It can therefore be seen that smaller RFID tags 20 can be signed using ECPVS than those suitable to be signed with RSA. By examining the data structures of the information in the tag 20, varied levels of redundancy can be provided by padding unused blocks with such redundancy. Also, if the ID code 40 does not need to be read by unauthorized readers 14, redundancy in the ID code 40 can be relied upon, or imposed, in order to provide a desired amount of redundancy. It has thus been recognized that the use of ECC signatures on an RFID tag 20 can offer similar protection to RSA signatures whilst being smaller and more efficient. This allows smaller tags to be used (or a more efficient use of the available data blocks) and/or multiple signatures to fit on the same tag. This cannot be done when using RSA signatures due to their overall size.
It will be appreciated that the principles described herein regarding the use of ECPV signatures are equally applicable to other signature schemes with message recovery such as the Elliptic Curve Digital Signature with Recovery (ECDSR) described in U.S. Provisional patent application No.______ entitled “Signatures with Confidential Message Recovery” filed on Sep. 4, 2007, the contents of which are incorporated herein by reference. When using ECDSR, the same considerations regarding security and tag size should be made similar to those discussed above.
In another embodiment, an ECDSA signature can be used for providing security to an RFID tag 20, in particular for a variation (b) ID code 40b where privacy is not an important issue.
ECDSA is a widely standarized elliptic curve-based signature scheme, appearing in the ANSI X9.62, FIPS 186-2, IEEE 1363-2000 and ISO/IEC 15946-2 standards as well as several draft standards.
ECDSA signature generation operates on several domain parameters, a private key d, and a message m, outputs the signature (r,s), where r and s are integers, and a summary of the algorithm is as follows.
ECDSA signature verification operates on several domain parameters, a public key Q, the message m, and the signature (r, s) derived above. ECDSA signature verification outputs a rejection or acceptance of the signature, and proceeds as follows.
As discussed above, an ECDSA signature is made up of two integers, namely r and s, both of which are the same size as the underlying field of the elliptic curve. For example, with a 160 bit curve, the signature size is 160×2=320 bits or 40 bytes.
If a message M is signed with ECDSA, then M, r and s are sent to the verifier, assuming that the verifier already possesses the correct public key Q.
The use of ECDSA in the authenticated RFID system 10 reduces the read/write times of digital signatures when compared to RSA, however, does not provide the privacy of ECPVS. The simplest way to implement ECDSA is to replace the 1024 bit RSA signature with an ECDSA signature of comparable security. The minimum curve size is typically required to be 160 bits, so an ECDSA signature occupies at least 320 bits. The smallest NIST recommended curve is 163 bits with a corresponding ECDSA signature size of 42 bytes. The following table illustrates the RFID memory required assuming that the ID CODE 40 occupies 96 bits.
The message that is signed using an ECDSA scheme can be a concatenation of the UID of the tag 20 and the ID code 40.
For a variation (a) code 40a, there is no Product ID 54. The signature element r can be computed using the padding alone. If the recovered message matches the expected padding, the signature is valid.
For a variation (b), the Product ID 54 may be replaced by an invalid value which does not correspond to any product. The actual Product ID 54 and the padding would then be used in the computation of r. If the recovered message matches the expected padding, the signature is valid. The reader 14 can then replace the invalid Product ID 54 with the recovered value to form the correct ID code 40b.
The ECC signature scheme that is chosen will typically depend on the amount of storage available on the RFID tag 20. It will be appreciated that the size of tag that is used can be chosen based on the security that can be acceptable, and based on the sizes that are available. An acceptable level of security is typically determined based on whether or not it would be economically feasible for a forger to forge a signature. If the redundancy in an ECPVS signature can be lowered and a forgery remain infeasible, then a smaller tag can be used. The examples used herein using 2048 bit and 256 bit tags are shown for illustrative purposes only and it will be appreciated that other tag sizes may instead be used, e.g. a 512 bit tag.
If a 2048 bit RFID tag 20 is used, either ECDSA or ECPVS can be used. ECDSA can be used to replace the RSA signature, and the digital signature will occupy 320 bits instead of 1024 bits, while offering the same level of security. The total storage required, including the ID code 40 is 416 bits or 13 memory blocks. It is therefore seen that using ECDSA allows multiple signatures to be written to a 2048 bit tag 20 whilst providing similar security and reducing the read/write time allowing an electronic pedigree to be established as the product 18 proceeds along the supply chain 22. However, unlike ECPVS, ECDSA cannot hide the product ID 54.
ECPVS can be used to further reduce the signature size and to hide the product ID 54 from readers 14 without the proper public key Zi. With the additional storage space in a 2048 bit tag 20, padding can be used to increase the redundancy to an acceptable level. Without considering any inherent redundancy in the ID code 40, 80 bits of padding can be added to provide the same security as a 1024 bit RSA signature. The total storage required would be 96 bits for the ID code 40, 20 bits for product ID 54 and 80 bits of padding for r and 160 bits for s. A total of 356 bits or 12 memory blocks are thus used for the padded ECPVS signature. If a lower level of security is acceptable, the memory requirement can be further reduced. The following table summarizes the signature schemes that can be used with 256 and 2048 RFID tags.
It can therefore be seen that a 2048 bit RFID tag 20 using ECPVS provides the ability to write more than one signature to the tag, e.g. at different stages in the supply chain 22 and allows the system 10 to hide the product ID 54 from unauthorized readers to add privacy. It will be appreciated that the above is for illustrative purposes only and that other tag sizes may be deemed appropriate according to the same principles and considerations discussed above.
As a result, taking certain parameters such as the level of acceptable security and the inherent redundancy offered by the ID code 40, a smaller tag 20 may be used, such as a 256 bit RFID tag 20 or a 512 bit tag etc. (not shown) using ECPVS with and without padding.
Where ECPVS is used to hide the product ID 54, the public keys Zi stored on the readers 14 should be physically protected and the distribution of the keys carefully controlled by, e.g. the CA 12. If each reader 14 contains its own public/private key pair, certificates can be encrypted for each specific reader 14 before distribution. The CA 12 issues certificates for both the signing stations 16 and the readers 14. Key pairs for the readers 14 and signing stations 16 are generated at manufacture time. As discussed above, each reader 14 has a validated list of public keys Wj for the signing stations so that the signatures can be validated. An example key distribution procedure using signer certificates CSIGNj is shown in
In step 100 the CA 12 obtains the appropriate public key Wj and generates the corresponding certificate CSIGNj at step 102. The certificate is then encrypted using the appropriate public key Zi for the reader 14 to which the certificate is being distributed at step 104 to obtain an encrypted version CSIGNj′. The encrypted version is then distributed to the appropriate reader 14 at step 106, which is received by the reader 14 at step 108. The encrypted version is decrypted by the reader 14 at step 110 using the private key zi to obtain the original certificate CSIGNj. The certificate is evaluated using the CA certificate CCA at step 114 where the CA certificate was obtained at step 112. If valid, the key Wj is obtained from the certificate and stored in the secure key store 36.
A signing operation is shown in
The signing station 16 then selects or reads from the tag 20, a serial number at step 214 (may use a default counter value) and a product code is selected at step 216 when applicable (variation (b)). Preferably, the serial number is pre-burned into ROM prior to arrival at the signing/programming facility as discussed above. This enables the manufacturer of the unsigned tag 20 to ensure that in order to compromise the security or attack the system, the hardware would have to be counterfeited rather than simply being able to use a genetic part and program a UID that suits the counterfeiter's purposes.
As noted above, the signing station 16 is typically pre-programmmed to automatically generate the proper signature type but in some cases may be programmed to provide the ability for an operator to choose the type of signature to write to the tag (e.g. ECDSA or ECPVS) at step 218, write the signature at step 219, and the tag 20 may then be programmed at step 220. A record is created at step 222 and preferably stored as a log report for tracking and auditing purposes. It will be appreciated that preferably each signing station 16 is pre-programmed such that any decision above is calibrated prior to the signer being deployed. However, if desired, the above-noted decision structures can be offered in a program, e.g. from drop down lists in a graphical user interface (GUI) (not shown). Such a GUI may also be used by a technician for programming and repairing the signing stations 16.
Step 220 is shown in greater detail in
A verification procedure is shown in
It is therefore seen that the read/write times and signature sizes can be reduced in an authenticated RFID system 10 by using ECC and in particular ECPVS and ECDSA when appropriate. The use of ECPVS further adds the benefit of being able to hide a portion of the product information which provides an added incentive to adopting RFID technology. ECPVS also provides the smallest signature at a similar security to an RSA signature. The smaller signature can enable multiple signing stations 16 to be used in the supply chain so that multiple signatures are written sequentially to each tag in the remaining available space and would then need to be verified sequentially. Therefore, it becomes easier to track the life of the product as it moves through the supply chain.
Turning now to
As discussed above, RFID tags 20 that include private or otherwise sensitive information such as a drug or product ID codes 54 can be hidden using ECPV signatures. However, since the hidden portion can be recovered using the public keys W1-T and Z1-N of the signing stations 16 and readers 14 respectively, when the overall system is intended to be distributed and scalable, it is generally preferable to protect the ECPV public keys in a secure manner and to monitor and control distribution thereof. The KMS 400 can be used to control distribution of the ECPV public keys such that only authorized readers 14 can recover the product ID code 54. As such, the keys W1-T and Z1-N in the following example, are to be referred to as “verification keys” given that by imposing such control over the use of these keys, they are not “public” in the traditional sense.
As can be seen in
As shown in
The tag programming stage 404 generally obtains or receives non-programmed RFID tags 20 (preferably containing a pre-burned serial number or UID), which are programmed using an RFID programmer 414 such that they include, e.g. a product ID code 54 such as an EPCglobal code as shown in
In general, the key inject system 417 is a system that is used to remotely monitor device registration and, if required, to meter the injection of unique and immutable information into the device. A complete description of the key injection system 417 is provided in co-pending U.S. patent application Ser. No. 11/450,418 filed on Jun. 12, 2006, the contents of which are incorporated herein by reference. In the present example, the controller 422a is a computer system that is remote to the RFID programming facility but is preferably under control of the company that produces the drug.
The key inject server 418a, signing agent 419a, and the RFID programmer 414 may or may not be in the same location or building. Preferably, a secure connection is established over a network connecting the components of the key inject system 417a internally and/or externally. The signing agent 419a comprises a data storage device 420, preferably in a hardware security module, which is a protected device used by the signing agent 419a to perform cryptographically secure operations such as encryption, decryption and signing and to store sensitive data.
The storage device 420 stores a key pair (wj, Wj) for each product type (e.g. for each drug). In this example, the drug manufacturer 402 is responsible for writing signatures 416 for five (5) different products and thus stores five key pairs as shown in
The signature 416 is generated by signing the tag 20 using the serial number, a drug ID code 54 specific to the product 18, and other supply chain 22 specific meta data using the private key for that product 18. The signature 416 is preferably an ECPV signature written to the tag 20 as described above.
As can also be seen in
Once the products 18 are labelled, they may then enter the supply chain 22, which may include steps of shipping, warehousing, distribution etc. As will be discussed below, additional signatures 416 may be added to the tag 20 and/or the signature 416 may be verified by RFID readers 14 at any one or all of the supply chain stages.
The product 18, in this case a drug, eventually arrives at one or more clinics or pharmacies 408, shown in more detail in
Each reader 14 is programmed at the reader manufacturer 410, shown in
As shown in
New key pairs (wj, Wj) for the signing stations 16 can be generated in a number of ways. For example, the key pairs may be generated in a secure environment by approved personnel and then uploaded to the signing stations 16 when appropriate. In another embodiment, the key pairs can be automatically generated by the signing agent 419 or key inject server 418. In yet another embodiment, the key pairs can be generated by the key inject controller 422 or the KMS 400 (i.e. from a remote location) and then securely transmitted or uploaded to the signing station 16 (i.e. through the key inject server 418 and agent 419). A new key pair (wj, Wj) is required each time that a new signing station 16 is deployed or when it is desirable for an existing signing station 16 to use multiple keys (e.g. for different product lines). If the signing station 16 generates a new key pair, a certificate request may be created, which contains the public key signed with the private key. The certificate request is then transmitted back to the KMS 400, which in this example is done through the key inject controller 422a. By using the key inject controller 422a, the KMS 400 is not only able to keep up to date key information, but use of the key inject controller 422a also enables the KMS 400 to inhibit fraudulent attempts to create new manufacturing lines without the proper consent. The KMS 400 is therefore able to track and obtain revenue for each tag 20 that is signed, for each product line that is properly registered.
The KMS 400 can also track the number of readers 14 that are programmed using the other key inject controller 422b. In this way, the KMS 400 can ensure that it is aware of all readers 14 that are capable of (and have permission for) verifying the signatures 416 signed by the signing stations 16. Where at least a portion of the recoverable contents of the signature 416 is sensitive or private information, this enables the KMS 400 to have greater confidence in the security and privacy of the overall system.
The KMS 400 may similarly track each signature verification or additional signature write operation that occurs as the tag 20 passes through the supply chain 22. The KMS 400 therefore not only securely distributes keys to the appropriate entities, but can also track points of revenue for the key distribution service. For example, the KMS 400 can track the number of tags 20 signed, and the number of readers 14 programmed and collect a per-device or per-tag charge. The KMS 400 may also track reader usage at the clinic or pharmacy 408 and collect a monthly or flat rate service fee for synchronizing the deployed readers 14 with up to date keys. The clinic or pharmacy 408 and the manufacturer 402 can, in turn, offer security and privacy to their customers and/or business partners.
Referring now to
The business request typically includes the parameters of the business relationship between the KMS 400 and the manufacturer 402. For example, there may be an agreement for a per-signature charge that can be collected by the KMS 400 for keeping the manufacturer 402 up to date with current and valid keys for generating the signatures. Other agreements such as flat rate monthly fees, one time fees etc. may also be established depending on the nature of the manufacturing environment, the product 18, volumes, price per unit etc.
Once the business agreements have been processed by the KMS 400, the KMS 400 then issues and returns a certificate CSIGNj, which corresponds to the key pair generated. The certificate is placed on the certificate server 428, together with a list of readers 14 that are entitled to the certificate. Therefore, it can be appreciated that the business request also typically includes details of preferred or mandatory distributors and/or parties in the supply chain 22. This enables the KMS 400 to track permissions for the readers 14 and to update their keys accordingly. The certificate CSIGNj is also stored by the signing station 16 for future reference as discussed above. It may be noted that the signing station 16 does not necessarily make use of the certificate in normal operations.
Once the signing agent 419a has been provisioned with one or more keys, which correspond to one or more products 18 on one or more product lines, tags 20 may then be signed during the programming stage 404. The key inject system 417a may be used to meter a credit pool to restrict the number of tags 20 that are signed or may instead simply track the number of tags 20 that are signed by using a secure reporting process. For example, after signing a tag 20 as shown in
Referring now to
The reader 14 in the meantime waits for updates from the KMS 400 since some of the keys may expire after a prescribed amount of time and new products 18 may need to be verified. The KMS 400 is able to update the reader 14 based on the feedback it obtains from the signing stations 16 (e.g. manufacturers 402) and based on product information, privacy issues etc.
Referring now to
It can be seen that the KMS 400 can operate in a semi-online manner and thus the readers 14 and signing stations 16 do not require a dedicated connection that is always online. The KMS 400 can update at appropriate times or have scheduled updates that require a connection to be established. It will be appreciated that where possible, a fully online system may also be used and/or a closed loop system within a single entity depending on the nature of the manufacturing environment and the supply chain 22 and distribution channels.
For the reader manufacturer 410, the KMS 400 may charge per reader 14 that is produced, which is tracked by the key inject server 418b and controller 422b and repotted back to the KMS 400 for billing and tracking needs. Once the readers 14 are deployed, the KMS 400 preferably provides a key update in exchange for a regular service fee. It will be appreciated that, although more difficult to track every read performed by each reader, e.g. due to missed reads etc., the KMS 400 can also charge per read. It will also be appreciated that similar revenue streams can be tracked and acquired through the various other stages in the supply chain 22 depending on the nature of the involvement of the other entities.
If the number of signers is large so too is the number of signatures and where the amount of space for storing the signatures is limited or at a premium (e.g. RFID tags 20), then the combined size of all the signatures can be costly. The following signature schemes reduce the size of multiple signatures by aggregating one or more signature components. The following schemes improve on traditional multi-signature schemes that compress two or more signatures.
Although particularly suitable for incorporating a contribution from multiple signing entities in an RFID signing scheme as discussed and exemplified herein, it will be appreciated that the signature schemes discussed below are applicable to any environment.
In one implementation the following aggregate signature schemes can be used with multiple signing stations (e.g. with RFID tags 20 in a pharmaceutical supply chain).
Traditionally, aggregate signatures have been proposed based on a digital signature algorithm using bilinear pairings. The algorithm defines an aggregate signature scheme, which is a traditional signature scheme equipped with two additional operations. The first operation takes a set of signatures S1, S2, . . . , St of messages m1, m2, . . . , mt signed by t users with public keys U1, . . . , Ut, and aggregates these into a single compressed signature s. The second operation verifies an aggregate signature s, given the messages m1, . . . , mt and the users' public keys U1, . . . , Ut. The signature s is valid if and only if every one of the si verifies for the associated message and user.
The following is particularly useful for ECPVS signatures although is equally applicable to other ElGamal signatures and similarly to other schemes such as ECDSA as will also be shown below.
When referring to ECPVS and ECDSA signature schemes, the terminology used above is repeated for consistency.
According to the above examples, it is assumed that there are T signers 16 that are each to sign a message M. For simplicity, it is also assumed that M is identical for all signers and, when signed using ECPVS, the recoverable portion H and visible portion V are also the same, e.g. the product ID and UID respectively. It will be appreciated that in some cases, V will be different for each signer j, i.e. Vj. It is also considered below that each signer may instead sign a different recoverable message Hj.
The following describes two types of aggregation, namely a semi-aggregate signature scheme and a fully-aggregate signature scheme. It has been found that the semi-aggregate signature scheme can compress the signatures to two-thirds of the original size. The fully-aggregate signature scheme is named as such since the compressed aggregate signature is the size of a single signature, no matter how many signing stations 16 are involved. The rate of compression is T-fold when there are T signers, and thus the fully-aggregate signature scheme can reach very high rates of compression when there are many signers.
Although full aggregation has better compression than semi-aggregation, it requires the co-operation of the signers to create the aggregate signature and thus may not be suitable where the signers are in different locations. Also, in other circumstances, e.g. where parties sign at different times, full aggregation may not be possible. The semi-aggregate signatures, discussed below, however, enable asynchronous signing and thus can be used instead of full-aggregation when necessary.
The semi-aggregate signature scheme using ECPVS for T signers begins with a first signer, namely Signer 1, computing a traditional ECPVS signature (c1,s1) by encrypting a hidden portion H in c1. Signer 2 then encrypts c1 when computing c2 rather than encrypting H, and then computes the other component s2 in the normal fashion, producing an updated signature (c2, s1, s2). This is repeated for each signer, until signer T encrypts cT-1 when computing cT and the semi-aggregate signature is (cT, s1, . . . , sT). In other words, each signer encrypts the previous “c” component whilst generating then next “s” component using the updated “c” component.
To verify the semi-aggregate ECPVS signature, a verifier 14 (e.g. RFID reader) first recovers cT-1 by performing an ECPVS verification on components (cT,sT) to decrypt cT-1 from cT. Next, the verifier recovers cT-2 from (cT-1,sT-1) and this is repeated until representation H′ of H is recovered. H′ is then checked for a particular characteristic, such as redundancy and, if the characteristic is present, message M can be reconstructed using H′ and V.
The semi-aggregate method is named as such for two reasons. First, the intermediate ciphertexts c1, . . . , cT-1 do not need to be included in the final ciphertext cT. Second, the verifier 14 has defended the acceptance or rejection of the intermediate signature(s) until all ciphertexts have been decrypted. For example, it is not necessary for signers 2 to T to add any redundancy. Therefore, the extra signers only add message expansion by adding the values S2, . . . , sT.
To further illustrate the semi-aggregate signature scheme, the following example is provided for three signers, making reference to
As shown in
A second signing station, Signing Station 2, then contributes to creating an updated, semi-aggregate signature rather then adding a separate signature. In this example, Signing Station 2 is at another point in the supply chain. Similar to Signing Station 1, Signing Station 2 generates an ephemeral key pair (k2,Q2) and an encryption key X2=KDF(Q1). However, at this stage, Signing Station 2 encrypts the existing signature component c1 using X2 to generate signature component c2. Intermediate signature component h2, integer e2 and signature component s2 are computed as before, however, the resultant updated signature now comprises the set of components (c2,s1,s2). As such, signature component c1 is encrypted in c2 and the “s” components (i.e. s1, s2 at this stage) are kept in the updated signature.
A third signing station, Signing Station 3, in this example the final signing stage, also contributes to the semi-aggregate signature, which currently comprises (c2,s1,s2) oil the RFID tag 20. Similar to the previous signing stations 16, Signing Station 3 generates its own encryption key, in this case k3, and then encrypts signature component c2 using k3 to generate an updated “c” signature component C3. Intermediate component h3, integer e3, and component s3 are computed as described above, and the resultant updated (and in this example final) signature comprises components (c3,s1,S2,S3).
At each stage, the new signature that embeds the “c” component of the previous signer 16, is written over the previous form of the semi-aggregate signature. Therefore, the semi-aggregate signature (cT,s1, . . . sT) is smaller than writing individual signatures ((c1,s1), . . . , (cT,sT)) to the RFID tag 20.
Referring now to
In stage 1, the verifier 14 computes h3′ using component c3 and the visible portion V, converts h3′ to an integer e3′, computes Q3′ using s3, e3′ and the public key W3 of Signing Station 3, and then generates X3′ by applying the same KDF to Q3′. The verifier 14 then obtains c2 by decrypting c3 using X3′ and a complementary decryption function, e.g. that denoted by “DEC” in
Now that the verifier has obtained c2, in stage 2, the verifier computes h2′ using component c2 and the visible portion V, converts h2′ to an integer e2′, computes Q2′ using s2, e2′ and the public key W2 of Signing Station 2, and then generates X2′ by applying the same KDF to Q2′. The verifier then obtains c1 by decrypting c2 using X2′ and a complementary decryption function.
In stage 3, the verifier computes h1′ using component c1 and the visible portion V, converts h1′ to an integer e1′, computes Q1′ using s1, e1′ and the public key W1 of Signing Station 1, and then generates X1′ by applying the same KDF to Q1′. Since c1 was generated by encrypting the recoverable portion of the message H, a bit string H′, which is a representation of H is then obtained by decrypting c1 using X1′. At stage 4, the verifier 14 then checks for the expected characteristic such as the redundancy of H′ in this example and, if sufficient, accepts H′ as the recoverable portion H and can reconstruct the message M, e.g. by combining H′ and V at stage 5. The verifier 14 may then conclude that each signer signed the message M represented by components (H,V).
It should be noted that although in this example, each signer 16 operates on the same visible portion V, the visible portion V may alternatively vary as Vi for each signer 16. In this alternative, each intermediate component h′ would be computed using the respective visible portion Vi and the verifier 14 would perform each verification stage using the same respective visible portion Vi. The above example using the sane visible portion V was provided for the sake of simplicity.
It can be seen that with the above semi-aggregate signature method, each additional signer 16, after the first signer 16 (e.g. Signing Station 1), at an 80 bit security level, each contributes approximately 160 bits of message expansion, which is the bit size of n and si at the security level of 80 bits. At 128 bits of security, the relatively marginal message expansion per signer would be approximately 256 bits. As such, the semi-aggregate signature method is particularly suitable for having multiple signing entities contribute to a signature thus enabling a verifier to ensure that, e.g., an RFID tag was handled by the expected participants in the supply chain. It will be appreciated that the semi-aggregate signature scheme provides similar advantages to any environment where storage or bandwidth or both are at a premium.
Variations on the above-described semi-aggregate method are possible. For example, each signer could add a small amount of redundancy at each signing stage. This could be done to ensure that the verification process, that typically requires some minimal amount of padding in the plaintext (e.g. 1 byte), does not need modification. This variation would be most suitable where the symmetric encryption scheme is able to use a plaintext of any byte length and does not make the ciphertext any longer than the plaintext.
Another variation is one where the intermediate plaintexts incorporate portions of the previous signer's “s” components. In this variation, the final signature would have the form (cT,sT) and the verifier 14 would recover cT-1 and sT-1 from cT and so on. Although this form of semi-aggregate signature has fewer components, it may not necessarily be shorter in length because the ciphertext cT is an encryption of cT-1 and sT-1 which itself is an encryption of cT-2 and sT-2 and so on. It can be expected that the length of cT be at least the length of H plus the sum of the lengths of s1, . . . , sT, which is about the same length as the first form of semi-aggregate signature (cT,s1, . . . sT).
In another variation, the intermediate plaintexts are the previous “s” values, without including the previous ciphertexts. In this variation, the final signature has the form (c1, . . . , cT, sT), where a verifier would recover ST-1 from cT and so on. Again, the signature length would be expected to be approximately the same as the first form (c1, s1, . . . , sT).
To further illustrate this variation on the semi-aggregate signature scheme, the following example is provided for three signers, making reference to
Similar to
As before, Signing Station 2, then contributes to the semi-aggregate signature by generating ephemeral key pair (k2, Q2) and computing X2=KDF(Q2). However, in this variation, Signing Station 2 encrypts existing signature component s1 using X2 to generate signature component c2. Intermediate signature component h2, integer e2, and signature component s2 are computed as usual, however, the resultant updated signature comprises (c1,c2,s2). As such, signature component s1 is encrypted in c2 and the “c” components (i.e. c1, c2 at this stage) are kept available directly from the signature.
As before, Signing Station 3 then also contributes to the semi-aggregate signature, by creating a resultant updated signature (c1,c2,c3,s3) as shown in
Therefore, at each stage in this variation, the new signature that embeds the “s” component of the previous signer 16, is written over the previous form of the semi-aggregate signature. Therefore, the semi-aggregate signature (c1, . . . cT, sT) is smaller than writing individual signatures ((c1,s1), . . . , (cT,sT)) to the RFID tag 20.
Referring now to
In stage 1, the verifier 14 computes h3′ using component c3 and the visible portion V, converts h3′ to an integer e3′, computes Q3′ using s3, e3′ and the public key W3 of Signing Station 3, and then generates X3′ by applying the same KDF to Q3′. The verifier 14 then obtains s2 by decrypting c3 using X3′ and a complementary decryption function, e.g. that denoted by “DEC” in
Now that the verifier has obtained S2, in stage 2, the verifier computes h2′ using component c2 and the visible portion V, converts h2′ to an integer e2′, computes Q2′ using s2, e2′ and the public key W2 of Signing Station 2, and then generates X2′ by applying the same KDF to Q2′. The verifier then obtains s, by decrypting c2 using X2′ and a complementary decryption function.
In stage 3, the verifier computes h1′ using component c1 and the visible portion V, converts h1′ to an integer e1′, computes Q1′ using s1 (which was recovered in stage 2), e1′ and the public key W1 of Signing Station 1, and then generates X1′ by applying the same KDF to Q1′. It can be seen that in this variation, X1′ can only be recovered by having previously recovered s1. Since c1 was, as before, generated by encrypting the recoverable portion of the message H, a bit string H′, which is a representation of H is then obtained by decrypting c1 using X1′. At stage 4, the verifier 14 then checks for the expected characteristic such as the redundancy of H′ in this example and, if sufficient, accepts H′ as the recoverable portion H and can reconstruct the message M, e.g. by combining H′ and V at stage 5. The verifier 14 may then conclude that each signer signed the message M.
It may also be possible that the recoverable message part H is not the same for each signer 16. For example, suppose that the recoverable message part is Hj for each signer 16. In a non-aggregated case, there is an ECPVS signature (cj,sj) for each signer 16 for message Hj, and the message Hj is encoded within cj. If the signatures were aggregated, each of the messages would need to be encoded.
The first approach to semi-aggregate signatures can be modified by appending the distinct messages Hj to the intermediate plaintexts. Since the intermediate plaintexts were taken to be the previous intermediate ciphertext, the previous ciphertext can be concatenated (or other method of combining) to the current recoverable message part. A first plaintext PT1 is H1 with any necessary padding to make it sufficiently redundant, and the intermediate plaintexts can be computed as PT2=c1∥H2 and so on.
For example, Signing Station 3 would generate ephemeral key pair (k3, Q3) and compute X3=KDF(Q3), compute c3=ENCx3 (c2∥H3), and then compute h3=HASH(c3∥V), convert to e3, and compute s3=e3w3+k3(mod n). The final aggregate signature in this variation has the form (cT,s1, . . . sT). However, the length of cT is at least the combined length of the distinct messages H1, H2, . . . , HT, instead of only the length of H. Although the signed message is longer, the message expansion would be the same because component cT is no longer than the total length of the recoverable message being signed. Alternatively stated, the message expansion mainly occurs due to the “s” components, which is true whether or not there are distinct recoverable portions Hj or a single recoverable portion H.
It will be appreciated that the other variants described above could also be implemented as semi-aggregate signature using distinct recoverable portions Hj as well as distinct visible portions Vj.
Semi-Aggregate Signatures used with Implicit Certificates
The semi-aggregate signature methods described above can also be used in conjunction with implicit certificates. For an implicit certificate having correspondents Alice and Bob, Alice receives from Bob or some directory, Bob's implicit certificate cB. From this single point, Alice computes Bob's public key as B=Hash(cB, IB)÷QCA, where IB is a string identifying Bob, a certifying authority (CA), and other pertinent information, such as a validity period, key usage etc.; and QCA is the public key of the identified CA. Now Alice can use B as the implicitly certified public key of Bob. The implicit nature is due to the fact that Alice can be sure that only Bob knows the private key associated with B, but she cannot be sure that Bob actually knows the private key. However, Alice soon expects Bob to use the private key and, as such, Alice would be able to detect this problem almost as soon as she needs to use B.
For semi-aggregate signatures, if Signer j has implicit certificate CSigner j, then the verifier 14 computes the public key of Signer j as QSigner j=Hash(CSigner j, ISigner j)+QCA j, where ISigner j is the certificate information associated with Signer j and QCA j is the public key of the CA who issued implicit certificate CSigner j.
For example, when the verifier 14 is recovering the plaintext that, say, Signing Station 2 signed using ECPVS, then the verifier 14 normally computes h2′=HASH(c2∥V), converts to integer e2′, and from that computes Q2′=s2G-e2′W and finally X2=KDF(Q2′). Where there is implicit certificate C2, the computations may instead be performed as: h2′=HASH(c2∥V)HASH(C2∥I2)mod n and X2=s2G+e2′C2+Hash(c2∥V)QCA2 respectively.
Known methods such as Shamir's trick and Solinas' “Joint Sparse Form” etc. allow an increase in the speed of the single computation of X2, compared to computing Q2 first from C2, and then X2 with the former equation. It will be appreciated that if an explicit certificate has been used, the verifier 14 would need to verify an explicit signature of the CA computed upon public key Q2, which would have taken longer.
It can therefore be seen that several variations of semi-aggregate ECPVS signatures can be used. For pharmaceutical supply chains 22 exemplified above, manufacturers, wholesalers, distributors and shippers may each add their own ECPVS to an RFID tag 20 attached to a package 18. Because the space available for data on an RFID tag 20 is limited, semi-aggregate signatures are advantageous in such an application by allowing more signatures to be fit into the same limited space. When the package 18 arrives at a pharmacy, the aggregate signature can be verified so that the pharmacy can conclude that the delivery was handled by authorized parties during the entire course of the supply chain 22. It will be appreciated that the above principles equally apply to other systems and should not be limited to pharmaceutical environments or limited to use in authenticated RFID systems.
In certain scenarios, where the co-operation of multiple signers can be achieved, a fully-aggregate ECPVS signature scheme can be used. In the following scheme, T signers cooperate to aggregate what would normally be T distinct ECPVS signatures into what is effectively a single ECPVS signature of all T signers.
In general, where Signing Station j has private key wj and public key Wj, Signing Station j generates ephemeral key pair (kj, Qj) and then encryption key Xj=KDF(Qj) as done in traditional ECPVS and explained in detail above. An aggregate encryption key is then computed as X=X1+X2+ . . . +XT.
As per the description above, the recoverable part H of message M is encrypted using the encryption key, in this case, the aggregate encryption key X to obtain a ciphertext c=ENCx(H). If the recoverable pat varies, then H is replaced by Hj and c is replaced by cj.
An intermediate component h=HASH(c∥V) may then be computed from c, the intermediate component h converted to an integer e, and each Signing Station j then computes an “s” component, e.g. as: sj=ewj+kj(mod n).
An aggregates value is then computed as s=s1+ . . . +sT and the aggregate signature is (c, s) where c encrypts H. If there are distinct recoverable message portions Hj, the aggregate signature would appear similar to the semi-aggregate signature, namely as (c1, . . . cT, sT). The latter aggregate signature is not as fully aggregate as the former signature since each ciphertext cj may contribute some message expansion to provide redundancy, whereas in full aggregation, message expansion does not grow as the number of signers grows.
To overcome this, it may be noted that the typical way to pad a recoverable message Hj for use in ECPVS is to prepend the message Hj with a sufficiently long string S so that Hj′=Sj∥Hj. If the signers all use the same Sj so that Sj=S, then it may be the case that cj=ENCX(Hi)=ENCX(S∥Hj)=c∥cj′ for some fixed signer-common string c and a signer-specific string cj′. If the symmetric encryption has the properties of a stream cipher, this may be likely. For symmetric encryption schemes such as AES in CBC mode, this will be true provided that S has a certain length that matches the block size of AES (which is typically 128 bits or 16 bytes). In this case, the aggregate signature may be represented more compactly as (c, c1′, . . . , cr′,s), and the only message expansion is (c,s), which, being the size of a single signed message, makes the approach fully aggregate.
It should be noted that when a stream cipher is used, wherever the messages have common parts, the ciphertexts also have common parts and, therefore, the common ciphertext portions may be sent just once to further reduce message expansion. As such, the commonality of the ciphertext portions can be exploited no matter where the commonality occurs, even if it is not at the beginning of the message. For messages with certain fixed formatting, this may occur, as well as for block ciphers applied in CTR mode (e.g. like a stream cipher) or in ECB mode (in 64 or 128 bit chunks).
Where there is a single visible portion V, for verification, the intermediate component can be computed as h′=HASH(C∥V), h′ converted to integer e′ as before, the ephemeral public key Q′ computed as Q′=sG−e′(W1+ . . . +WT), and from that the decryption key computed as X=KDF(Q′). It should be noted however that where there are distinct visible portions Vi, each intermediate component is computed as hj′=HASH(c∥Vj) and the ephemeral public key Q′ computed as Q′=sG−(e1′W1+ . . . +eT′WT). It should also be noted that if the recoverable portion H varies by signer 16, each occurrence of c is replaced by cj.
Not only is the computation Q′=sG−e′(W1+ . . . +WT) generally more efficiently computable, it will indicate that (c,s) is a valid ECPVS signature for public key W1+W2+ . . . +WT.
The verifier 14 may then obtain the plaintext H′ by decrypting c using the decryption key X, which can be derived from the ephemeral key Q′ using the same KDF. If H′ has the necessary redundancy, then the message M can be reconstructed by, e.g. concatenating H′ and V and the verifier 14 can then conclude that each signer signed the message.
Referring to
It can also be seen in
In the case where each signer 16 uses a distinct recoverable portions Hj, the step of recovering Hj′ is replaced with Hj′=DECX(cj).
It should be noted that the fully aggregated method requires the active participation of each signer 16. If a new signer 16 is to be added to the aggregate, then the previous signers will need to contribute new contributions sj to the signature component s. This may be disadvantageous when compared to semi-aggregate ECPVS, where any new signer could add in an extra signature. As such, these considerations can be used to determine whether semi-aggregate or fully-aggregate signature are more appropriate for a given application.
For security reasons, it is preferable in aggregate ECPVS that signer j who obtains certificates for QSigner j, provides a proof-of-possession (POP) of the private key to some CA (or failing that, to the verifier). Typically, POP for signing public keys is done by signing a certificate request sent to the CA. Verifiers can usually rely on a CA to obtain POP from the subject of each certificate as it issues.
Also, fully aggregated ECPVS signatures can work in conjunction with implicit certificates. For example, if Signer j has implicit certificate CSigner j, then the verifier 14 can compute the public key of Signer j as Wj=Hash(CSigner j, ISigner j)CSigner j+QCA j, where ISigner j is the certificate information associated with Signer j and QCA j is the public key of the CA who issued implicit certificate CSigner j. As with semi-aggregate signatures, the computation of Qj can be substituted into the equations for computing X, which may offer better performance rather than computing Qj first and then X.
Other ElGamal type signatures can use the principles above with respect to ECPVS to apply the semi-aggregate and fully aggregate methods described above. Other signature schemes, such as ECDSA, have features that are sufficiently different warranting additional consideration.
It may also be desirable to aggregate ECDSA signatures, for example in a pharmaceutical supply chain 22 where ECDSA is used for signing the RFID tags 20. Such an embodiment is shown in
Similar to the above, it is considered how T signers can cooperate to produce a fully aggregate signature that is valid if and only if the corresponding T ECDSA signatures would have been valid. Reference is made to the above-description of ECDSA.
Each signer chooses a random value kj and computes a value Rj=kjP, which is sent to the other signers. The common value of R is computed as R=R1+ . . . +RT. The corresponding k such that R=kP would thus be k=k1+ . . . +kT. None of the individual signers knows the value k since signer j only knows its contribution kj to the common key k. Similarly, d=d1+ . . . +dT represents a common private key of the signers, where none of the individual signers knows the whole value of d. The corresponding public key would thus be computed as the sum of the individual signers' public keys where W=dP=d1P+ . . . +dTP=W1+ . . . +WT.
The first signature component r is computed as r=f(R), where f( ) is the function that is normally used in the particular implementation of ECDSA to convert the x-coordinate of a point to an integer, and reduces the integer modulo n (also see above definition of ECDSA).
Finally, the second signature component s can then be computed as s=k−1(H(m)+rd) mod n and the signature can be computed as (r,s), which will be a valid ECDSA signature on message M tinder common public key W=W1+ . . . +WT.
Verifying the aggregated ECDSA signature can be done by the verifier 14 first computing the common public key W=W1+ . . . +WT, where Wj is the public key of Signing Station j; and then verifying (r,s) (e.g. by reading RFID tag 20) under common public key W.
The value s is computed from d and k, which are secret values that no individual signer 16 shown know as a whole. Similarly, no signer 16 should know any other signer's private keys. To preserve this level of security, the signers 16 can use one of the known methods for doing secure multiparty computation, which allows multiple entities to compute a value that is a function of the multiple individually held secrets, without any party revealing anything about it own secrets to the other parties. Known methods for secure multiparty computation are given in Chaum et al., “Multi-party unconditionally secure protocols”, in Proc. of ACM STOC'88, 1988; and Ben-Or et al., “Completeness theorems for non-cryptographic fault-tolerant distributed computation, in Proc. of ACM STOC'88, 1988, pp. 1-10.
It can therefore be seen that multiple signatures from multiple signers can be achieved using less message expansion. Both semi-aggregate and fully-aggregate signature schemes can be used and are particularly adaptable to ECPVS and ECDSA. Multiple signatures are particularly useful in applications where the amount of storage space for such signature is at a premium and multiple signatures enables signatures to be written at various stages in a process, such as an RFID tag 20 in a pharmaceutical supply chain 22.
Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto.
This application claims priority from U.S. application. Nos. 60/824,921 filed on Sep. 8, 2006; 60/865,566 filed on Nov. 13, 2006; and 60/929,816 filed on Jul. 13, 2007; the contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60824921 | Sep 2006 | US | |
| 60865566 | Nov 2006 | US | |
| 60929816 | Jul 2007 | US |
