Integration of Digital Signatures into the Existing Object

Memory Model (OMM) - Concept Paper

Sascha Groß, Sonke Knoch, Jens HaupertGerman Research Center for Artificial Intelligence (DFKI)

Saarbrucken, Germany{firstName.lastName}@dfki.de

http://www.dfki.de

Version 1.0

January 28, 2014

Contents

1 Abstract 3

2 Solution 3

3 Summary of the general design ideas 43.1 Backwardcompatibility with older versions of OMM without signatures . . . . . . . 43.2 The server-side architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.1 Authority Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.2 Storage Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Implementation 54.1 Server-side implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1.1 Details on the Authority Server URL . . . . . . . . . . . . . . . . . . . . . . 54.2 Key generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.3 Client-side implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.4 Signature implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.4.1 The X509 custom Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 64.4.2 Choice of the hashfunction . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.5 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Examples of actions 115.1 Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.1 Creating a new block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2.2 Modifying an existent block . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2.3 Erasing an block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Testing 15

CONTENTS CONTENTS

7 Comments on the subject security 157.1 Discussion of several attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.2 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

References 17

2

2 SOLUTION

1 Abstract

The OMM gives the user the possibility to write a bunch of data to the product memory. Someof them include usefull additional information about the product and are not safety critical butfor some other information it is very important that they are correct. Because we want to allowsome kind of general access to the contents of an product memory we can not simply just givesome users the right to change data but have to provide some kind of authenticity. It should ingeneral be possible for everyone to change some data of a product memory but it should not bepossible to do so in the name of some authorized institution. It is one task of the OMM to explainthe user if the provided data are save or could potentially be modified. The content of this paperis to show the integration of this authenticity into the existing OMM.

2 Solution

In order to be able to detect modifications an signature algorithm should be applied. A checksumlike CRC or a cryptographic hash function can not be applied for this purpose because they onlycould protect the user from incorrect transmissions but not from intentionally manipulations. AMessage Authentication Code (MAC) like for example HMAC in generally is suitable for protect-ing the users against manipulation but in this methods a verifier needs to know the secret keys ofthe signers. Because in our example every user, especially the users who are not in the productchain, need to be able to verify the content of the data, this method can not be applied. Whatremains is some kind of signature algorithm.

At the time of this writing it appears that the RSA, the Digital Signature Algorithm (DSA) and itsmodifications with ecliptic curves (ECDSA) represent one solution. Another possibility would be asigning according to the Merkle Darmgard construction. At the moment, there already exist somecollisions for this construction, such that we decided to concentrate on RSA or DSA/ECDSA. Ifwe compare these three algorithms in general we have to say that applied with repective sufficientkeylengths they all are secure at the current time. The performance of these algorithms scaleswith the keylength we are interested in and allows us to choose an preferably strong algorithm.According to some articles, the DSA with equal keylengths seems noticeably harder to break thanthe RSA algorithm. Concerning the comparison of the DSA with the ECDSA algorithm we haveto consider the fundamental mathematical problems of these two algorithms. While the DSAalgorithm is based on the Discrete Logarithm Problem (DLP) the ECDSA algorithm is based onthe Ecliptive Curve Problem (ECP). According to different papers, the ECP seems clearly harderto solve than the DLP. So we choose the ECDSA algorithm for reasons of security and performance.

The ECDSA uses a hash function. For common SHA-1 was used for this purpose. But becausethe strength of the used hash function strongly influence the strength of the whole signature andat the current time numerous collisions for SHA-1 exists we cannot use SHA-1 anymore. At thetime of this writing the SHA-2 function with an keylength of 512 bytes (SHA-512) is a strongfunction which should be secure against expected attackers for one or two decades. We will usethis function in the ECDSA Algorithm.

The named method is sufficient to guarantee the authenticity of the named source. In addition,it is possible to implement a software based protection mechanism who guarantees the recover-ability of modified or deleted data. For this purpose, a transaction based history like it is used inmany Data Base Management Systems (DBMS) could be used. If we want to provide a physicalprotection this history can be saved on a external data base server and accessed by the regularusers and anybody in terms of verification.

3

3 SUMMARY OF THE GENERAL DESIGN IDEAS

3 Summary of the general design ideas

3.1 Backwardcompatibility with older versions of OMM without signa-tures

An important property of the OMM is the backward compatibility. Because we want users of oldversions of the OMM to keep able to use their products also with new client software we regardthe signature as optional. However, newer implementations of the OMM should give the customera warning that the provided information possibly could not be true but the client never shouldrefuse to read from an tag.

3.2 The server-side architecture

The OMM in general should be able to include any kind of data. This in particular means thatthe size of the provided data can be arbitrarily big. For this reason, it is impossible to store alldata on the product memory, e.g. an RFID tag itself. Instead, we have to store just an link to anexternal source. If we assume the OMM will be used in millions of products and we also assumethat the data per product can be arbitrarily long we easily realize that it would not be feasible tostore all the information on just one server or a few servers that could be provided by one centralinstitution. Instead, we have to share the data on a lot of different servers provided by for examplethe customers of the products themselves. Because of the big number of such servers we can nottrust these servers.

Since the only data the customer has to trust are the public keys of the signers, we store themseperately on an external server that is administrated by some trusted authority. In this paperwe will call the server where the data of the memory are stored ”Storage Server” while we call theother one ”Authority Server”. With the public keys the customer and anybody else can check thedata on the nontrusted servers for authenticity.

The distribution of the keys for the DSA respectively ECDSA algorithm as well as the access tothe product memory could be implemented by a web application. We will in the following brievlysummarize the functions and properties of the Authority Server and the Storage Server. Noticethat the communication to the Authority Server as well as to the Storage Server has to be doneover an secure channel.

3.2.1 Authority Server

We assume that we can trust the Authority Server completely. If the Authority Server missbehaveseverything up to an universal break (but not a total break as we later will see) can happen. Theauthority server has the following tasks:

• Saving and providing the public keys and issue certificates of all whitelisted users for all otherusers for verification or for looking up if some user has the right to write or read somethingon the Storage Server.

• Saving from each memory that is connected with the Authority Server the signature of thelatest entry.

• Saving and mantaining a blacklist of revoked certificates.

As easily can be seen there is very little traffic for one product memory to/from the AuthorityServer. This is desirable because we want one Authority Server to be responsible for a bunch ofStorage Servers.

4

4 IMPLEMENTATION

3.2.2 Storage Server

The assumption is that we do not trust the Storage Server at all. We assume that there might bea malicious hoster of an Storage Server which is interested in arbitrarily manipulating data. Forthat case we want to guarantee that the user at least will be notified that some data is not signedcorrectly. An ordinary Storage Server saves the complete product memory as well as a history ofall states of all blocks that have been in the product memory since creation of the memory.

4 Implementation

4.1 Server-side implementation

SignatureScheme

Figure 1: Scheme of a signature

Figure 1 is a scheme of the certificates in signed OMS. There exists one certificate for each Blockincluding a link on the id of the previous (p id), the id of the current block (c id) which is addedfor efficency reasons and a hash value (block hash) as extensions. The hash value block hash isan hash of the hash of the previous block concatenated with the metadata and the payload of thecurrent block. So the metadata as well as the payload of each block are signed. And it is notpossible to delete or add blocks to the memory in an unauthorized way. The p id is necessaryto prevent an malicious OMS server from simply removing a whole block. Notice that the OMMheader and the Table of Contents (ToC) are not signed because they only contain describing data.

4.1.1 Details on the Authority Server URL

At some point in a reading operation as well as in a writing operation the client and the StorageServer need to know the URL of the corresponding Authority Server. This URL is delivered in anexternal config file. In the first step, the config file will reference the Authority Server immediatlywhile later on this can be extended to an two step procedure where the link just references andistribution server which returns the Authority Server for the wished Storage Server.

4.2 Key generation

The keypair of each client is generated by the client himself. It authenticates to the authorityserver and just submits its public key.

4.3 Client-side implementation

The client side implementation should be done in Java or C#. The advantage of Java clearly isreasoned by its platform independence. The program could easily be executed on private com-puters, embedded systems or on any android phone with NFC capabilities. This clearly provides

5

4.4 Signature implementation 4 IMPLEMENTATION

Figure 2: The cryptographic abstraction system in JAVA

a lot of flexibility for every users. For the used ECDSA and SHA algorithms there are differentlibraries which can be included easily into the project and are known to be good implemented.In both languages there exists an two step concept for using cryptographic functions of externallibraries, cf. [1], [2]. We will explain this concept for Java but it can be easily transferred to C#.

Client function calls are primary directed to abstract layers. Such abstract layers are build by theJava Cryptographic API (JCA) and the Java Cryptographic Extension (JCE). These frameworksprovide interfaces for client function calls. These interfaces in turn are implemented by differentso called ”Cryptographic Providers” such as Bouncy Castle, IAIK or Cryptix. Figure 2 shows theschema.

As shown in Figure 2 one of such Cryptographic Providers is Bouncy Castle. We will use theirlibraries in our implementation of an appropriate signature. Their library includes the ECDSAalgorithm as well as the needed hash functions in different versions.

4.4 Signature implementation

4.4.1 The X509 custom Certificate

Each block is signed by a signature. The signature itself is implemented by an X509v3 certificate.As extension in the certificate we will save the signature of the current block. In order to pre-vent a malicious hoster of the Storage Server from removing a whole block we add an additionalid that references the previous block. By saving the last certificate on the authority server weguarantee on this way the completeness of all blocks or at least the verification of the completeness.

6

4.4 Signature implementation 4 IMPLEMENTATION

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: sha512WithECDSAEncryption

Issuer:

C=AT,

ST=Steiermark,

L=Graz,

O=TrustMe Ltd,

OU=Certificate Authority,

CN=CA/Email=ca@trustme.dom

Validity

Not Before: Oct 29 17:39:10 2000 GMT

Not After : Oct 29 17:39:10 2001 GMT

Subject:

C=AT,

ST=Vienna,

L=Vienna, O=Home,

OU=Web Lab,

CN=anywhere.com/Email=xyz@anywhere.com

Subject Public Key Info:

Public Key Algorithm: ecdsaEncryption

ECDSA Public Key: (1024 bit)

Modulus (1024 bit):

....public_key....

Exponent: 65537 (0x10001)

X509v3 extensions:

Previous Block ID:

23

Signaturevalue\ of current Block:

....signature_value....

Signature Algorithm: sha512WithECDSAEncryption

....signature_value....

The whole block with the certificate:

<omm:block omm:id="block\_123">

<omm:namespace>http://www.w3.org/2005/Incubator/omm/ns/sample</omm:namespace>

<omm:format omm:schema="http://www.w3.org/2005/Incubator/omm/schema/sample.xsd"

omm:encryption="none">application/xml</omm:format>

<omm:creation>

<omm:creator omm:type="duns">195505177</omm:creator>

<omm:date omm:encoding="ISO8601">2011-01-30T18:30:00+02:00</omm:date>

</omm:creation>

<omm:contribution>

<omm:contributor omm:type="email">user@example.com</omm:contributor>

<omm:date omm:encoding="ISO8601">2011-01-31T08:12:50+02:00</omm:date>

</omm:contribution>

<omm:title xml:lang="en">sample title</omm:title>

<omm:title xml:lang="de">Beispieltitel</omm:title>

<omm:description xml:lang="en">sample description</omm:description>

<omm:description xml:lang="de">Beispielbeschreibung</omm:description>

<omm:description xml:lang="fr">description example</omm:description>

<omm:type>http://purl.org/dc/dcmitype/Dataset</omm:type>

<omm:subject>

7

4.4 Signature implementation 4 IMPLEMENTATION

<omm:tag omm:type="ontology"

omm:value="http://o.org/def.owl ManufacturerData" />

<omm:tag omm:type="ontology"

omm:value="http://www.w3.org/2005/Incubator/omm/ontologies/v1/phase.owl

Production"/>

<omm:tag omm:type="text" omm:value="ingredients" />

<omm:tag omm:type="text" omm:value="norms">

<omm:tag omm:type="text" omm:value="din">

<omm:tag omm:type="text" omm:value="e12" />

</omm:tag>

</omm:tag>

</omm:subject>

<omm:link omm:type="url" omm:hash="d32b568cd1b96d459e7291ebf4b25d007f275c9f1

3149beeb782fac0716613f8">http://www.w3.org/2005/Incubator/omm/samples/p1/ext.xml

</omm:link>

<omm:payload omm:encoding="base64">(...)</omm:payload>

<omm:certificate>

<data>

<version= 3 />

<serial_number=1 />

<signature_algorithm=sha512WithECDSAEncryption/>

<Issuer>

<C=AT/>

<ST=Steiermark/>

<L=Graz>

<O=TrustMe_Ltd/>

<OU=Certificate Authority/>

<CN=CA Email=ca@trustme.dom/>

</Issuer>

<Validity>

<Not_Before="Oct 29 17:39:10 2000 GMT"/>

<Not_After="Oct 29 17:39:10 2001 GMT"/>

</Validitiy>

<Subject>

<C=AT/>

<ST=Vienna/>

<L=Vienna, O=Home/>

<OU=Web Lab/>

<CN=anywhere.com Email=xyz@anywhere.com/>

</Subject>

<Subject Public Key Info>

<Public_Key_Algorithm= ecdsaEncryption/>

<ECDSA_Public_Key_1024bit/>

<Modulus_1024bit=....public_key..../>

<Exponent=65537/>

</Subject Public Key Info>

<X509v3_extensions>

<Previous_Block_ID=23/>

<Signature_value_current_block=....signature_value.... />

</X509v3_extensions>

<Signature Algorithm="sha512WithECDSAEncryption"

signatureValue=....signature_value..../>

</X509v3_extensions>

</omm:certificate>

8

4.5 Requests 4 IMPLEMENTATION

</omm:block>

4.4.2 Choice of the hashfunction

The presented ECDSA algorithm as well as the most of other signature algorithms uses a hash-function in the computation of the signature. Because the runtime of this hashfunction is crucialfor the runtime of the whole signature it is important to choose a hashfunction that provides highsecurity with a low computation time.

In different testing runs following armortized runtimes for the MD5, SHA1, SHA256, SHA384 andSHA512 were determined. The results are shown in Table 1.

MD5 SHA1 SHA256 SHA384 SHA51232 15 16 15 16

Table 1: Comparison of common hash functiosn

The provided data are presented in milliseconds. The input string was an randomly generatedalphanumeric string of 100KB length. The computation was done on an current i5 processorrunning the JRE 1.7.

4.5 Requests

The communication between the the Storage Server, the Authority Server and the Client is donevia XML requests. In the following, examples of each possible command an their correspondingresponses are listed:

• UpdateLastCertificateRequest:

The UpadteLastCertificateRequest is send to the Authority by the client after a write op-eration was performed. It includes the self created certificate of the new data submitted aswell as an URL identifiying the Storage Server, the place where the memory is stored.

<xml>

<Command>UpdateLastCertificate</Command>

<Certificate>example_cert</Certificate>

<StorageServerURL>http://mystorageserver/memory1</StorageServerURL>

</xml>

After an successfull execution there will be just an acknowledgement responded by the serverwith return code 200 - OK.

• PublicKeyRequest:

The PublicKeyRequest is send by an user to the Authority Server in order to get the publickey of an legitimate user.

<xml>

<Command>PublicKeyRequest</Command>

<UserID>1</UserID>

</xml>

9

4.5 Requests 4 IMPLEMENTATION

<RequestResult>

publicKey1

</RequestResult>

• GetLastCertificateRequest:

This request is send to the Authority Server to get the last certificate of a storage.

<xml>

<Command>GetLastCertificateRequest</Command>

<StorageServerURL>http://mystorageserver/memory1</StorageServerURL>

</xml>

<RequestResult>

example_cert

</RequestResult>

• BlacklistRequest:

This request is used by the Storage to get information about revoked certificates from theAuthority Server.

<xml>

<Command>BlacklistRequest</Command>

<StorageServerURL>http://mystorageserver/memory1</StorageServerURL>

</xml>

<RequestResult>

false

</RequestResult>

• GetBlockRequest:

This request returns a Block for a given BlockID.

<xml>

<Command>GetBlockRequest</Command>

<BlockID>4</BlockID>

</xml>

<RequestResult>

[[...OMM-Block...]]

</RequestResult>

• GetCertificateRequest:

This request returns just the certificate for a given BlockID.

<xml>

<Command>GetCertificateRequest</Command>

<BlockID>4</BlockID>

</xml>

<RequestResult>

[[...X.509-Certificate...]]

</RequestResult>

10

5 EXAMPLES OF ACTIONS

• LockOMSRequest:

This request is used to lock the OMS temporarily so that no inconsistency in the storage orfailed validations on client side can happen.

<xml>

<Command>LockOMSRequest</Command>

</xml>

<RequestResult>

<LockID>23</LockID>

</RequestResult>

• SendBlockRequest:

This request sends an block to the OMS server. It returns true if the block was savedordinary or false otherwise.

<xml>

<Command>SendBlockRequest</Command>

<OMM-Block>[[...OMM-Block...]]</OMM-Block>

</xml>

<RequestResult>

true

</RequestResult>

5 Examples of actions

5.1 Reading

In this case we want to read an block t out of n blocks. The diagrams shown in Figure 3 and 4illustrate the procedure.

The reading process begins with the request of the latest certificate from the Authority Server.At the next step, we load the latest certifiicate from the OMS server and compare these two. Wethen proceed by loading the Certificate Cn−1 and check the validity of Cn by using the signatureof Cn−1, and the signature of the current block. If both checks succeed we continue by doing thesame with the respective previous blocks iteratively until we reached the block we want to read.If at some step the validation of an certificate or the initial comparison of the two certificates failsa honest client informs the authority server about that.

5.2 Writing

5.2.1 Creating a new block

The following diagrams (cf. Figure 5 and 6) show the creation of a new block. We will see thatmodifing an existent block or erasing it are very similar to this case:

11

5.2 Writing 5 EXAMPLES OF ACTIONS

Use_Case_writing

Figure 3: A reading operation in OMS

Use_Case_writing

Figure 5: A writing operation in OMS

Before an actual writing can take place the OMS Server has to be locked, because if for examplesomeone else writes at the same time to the OMS Server as the first one, one of the certificateswill not be valid. After the lock in the OMS Server is done, the client sends a request to theauthority server with which the authority server is locked and the latest certificate of an OMSMemory is requested. The authority will lock and send the user the requested certificate. Theclient computes a new certificate Cn including latest certificate Cn−1 and signature value of thecurrent block Sn. The signature of the current block is build as signature of the signature of theold block, the current metadata and the current payload: Sn = sig(Sn−1,Mn, Pn). In the nextstep the block with the according certificate is send to the OMS Server. Before actual writing, the

12

5.2 Writing 5 EXAMPLES OF ACTIONS

Figure 4: A reading operation in OMS

13

5.2 Writing 5 EXAMPLES OF ACTIONS

sd OMM Writing

LockRequest

LockRequest-Answer

GetLastCertificateRequest

GetLastCertificateRequest-Answer

Compute new certificate

SendBlockRequest

SendBlockRequest-Answer

BlacklistRequest

BlacklistRequest-Answer

Unlock

UpdateLastCertificateRequest

UpdateLastCertificateRequest-Answer

Unlock

Figure 6: A writing operation in OMS

14

7 COMMENTS ON THE SUBJECT SECURITY

OMS Server checks the signature an then asks the Authority Server if the used public key is inthe blacklist. If either the validation fails or the used public key is in a black list the OMS serverrefuses to store the data. The result of the writing is then told to the client. If the data werewritten to the OMS server then the client sends his last certificate to the authority server. At theend, the authority server and the OMS server unlocks and the next client can write.

5.2.2 Modifying an existent block

A modification is simply modelled as the change of an bool field expired in the block to changethe reading of the old block and the writing of a new block with modified data afterwards.

5.2.3 Erasing an block

Each block has an field erased which is set if an block shall be erased.

6 Testing

We tested the presented use case scenarios in a common test method. This method creates first amemory and an arbitrary number of example Blocks created by createExampleOMMBlock() andthen adds them to the memory by calling addSecureBlockAndSave(). addSecureBlockAndSave()writes the memory to an empty XML file and sends the certificate of the last certificate via anUpdateLastCertificateRequest to the Authority Server.

For some performance testing we created 10.000 blocks in the mentioned manner and measueredthe time needed with and without the additional security signature. Because the creation of anexample Block and the addition to the memory takes very little time compared to the creation ofthe two signature values needed for creating an OMMSecureBlock we experienced an very highoverhead. The creation of 10.000 without the security feature took about 4s while the durationof the creation with the security signature took about 90s. However, we think that this overheadis acceptable because it only occurs when blocks are created which are very large. In a commoncase, blocks will not be as large as in the test scenario while in the most frequent case of readingthe signature values of the blocks do not have to be recomputed but just verified.

After checking the time needed to create such an memory our test proceeds by calling the methodcheckErroneousBlock() which gets the path to an manipulated OMM and the wished validationresult as parameters. checkErroneousBlock() validates the given manipulated or defect memoryand compares it with the expected validation result it returns an error if the validation of the defectblock succeeds or does not result in the expected error. By doing so we tested the case wherean block in the memory is no OMMSecureBlock, but a normal OMMBlock, an simple certificatemanipulation, an manipulation attempt by trying to insert an foreign self signed block, the usageof an expired certificate and some attempt trying to pretend that some block is overwritten bysome other block by permuting the order of the blocks in the OMM.

7 Comments on the subject security

7.1 Discussion of several attacks

• Attack: Changing of metadata or payload without changing the signature.An attacker could simply try to change some metadata or the payload of an block withoutchanging the signature value in the certificate extension.

15

7.2 General considerations 7 COMMENTS ON THE SUBJECT SECURITY

Protection mechanism:Everytime a block is read the signature value of the certificate of the block is checked. Thischeck will fail if just the payload or the metadata are changed.

• Attack: Changing of metadata or payload with computing new signature values.An attacker could try to recompute an certificate value as well as the signature value in thecertificate extension. In this case he has to add his own created public key as the public keyof the certificate or the validity check will immediately fail.

Protection mechanism:An reading client checks if the given public key in the certificate is really the public key ofthe user via an PublicKeyRequest to the AuthorityServer. If these keys are not equal thecheck will fail.

• Attack: Erasing of the complete memory.An attacker could erase all blocks of the memory pretending the memory was empty.

Protection mechanism:In this case an GetLastCertificateRequest will return an valid certificate which obviously isan contradiction to the empty memory.

• Attack: Inserting a not linked block.An attacker could insert an self created and self signed block that is not linked via p id atall.

Protection mechanism:In all read blocks it is checked that the p id of the next block actually points to the BlockIDof the current block. Even if an attacker chooses the id of an existent block as the blockIDan error occurs.

• Attack: Removing an block.An attacker could simply remove an whole block with its certificate.

Protection mechanism:If this block is the last block see the case of removing the whole memory. If this block isnot the last block there exists the next block which points to the block deleted via its p idwhich does not exist anymore.

7.2 General considerations

There are several things to consider to use this method in the right way. The applied method isconsidered to be secure from all authorities in cryptography in the current time. But one weakpoint is the sharing of the private keys. If an attacker has access of such a private key he is able tomodify and sign data in the owner’s name. For that reason, it is very important to share the keysover a secure connection. One possibility would be an Secure Sockets Layer (SSL) connection toan webservice deploying the keys.

A second consideration is that even with perfectly right use of this technology this technologydoes not prevent some attacker to write an arbitrarily link to the tag. With this link he could forexample point to his own product memory and so give the user wrong information

16

REFERENCES REFERENCES

References

[1] http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/

codec/digest/DigestUtils.html#getSha512Digest%28%29

[2] http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/

codec/digest/DigestUtils.html#getDigest%28java.lang.String%29

17