Device and method for data timestamping

A storage device includes a trusted clock, a memory, a time-stamper and a digital signer. The device is adapted to store to the memory data that has been time-stamped by the time-stamper, with a time obtained from the trusted clock, and digitally signed with a digital signature by the digital signer.

DESCRIPTION OF THE PREFERRED EMBODIMENT Current trusted third party time-stamping systems, as shown in FIG. 1 , involve the transmittal of data over a network to the trusted third party for time-stamping. Data, or a digest of the data, is sent from a computer (e.g. a PC 1 ) via telecommunications 2 to a network, e.g. the internet 3 . The data is routed on the internet 3 to a trusted clock 4 attached to the internet via telecommunications 5 and is time-stamped. Once time-stamped the data may be passed back to the internet via telecommunications 6 and may then be sent via telecommunications 7 to a storage device 8 for storage or it may be sent back to the originator of the data via telecommunications 9 for storage. This introduces delays, has a throughput which is limited by the bandwidth of the network and has opportunities for data interception, connections failures, and falsification of time-stamps. Digital signatures, see for example FIG. 2 , reduce the opportunities for data tampering and falsification. This involves passing the data through a hashing algorithm to obtain a digest of the message. A specific digest is almost impossible/very difficult to produce from data other than the original data hashed. The digest is then encrypted using an asymmetric encryption private key to provide a signature. The signature is appended to the data and transmitted with it. A third party who has the public key which is complementary to the private key used in the encryption process can decrypt the signature to obtain the digest. The third party can rehash the received data and calculate the digest of this. The digest from the signatures and the rehashed digest are compared, if they do not match then the data has been tampered with. In one embodiment of the present invention, shown in FIG. 3 , data from data source 10 is passed into a storage device 12 . The storage device 12 (with its boundary shown as 13 ) comprises an interface 14 , a data buffer 16 , a secure controller 18 with an associated trusted clock/signature module 20 , and data storage media 22 , 22 b, 22 c. The data from the external data source 10 may or may not be encrypted prior to being passed into the storage device 12 . The external data source 10 may be for example a LAN, the Internet, a PC or a server. The interface 14 serves to ensure interoperability and consistent data handling between different data sources 10 and the storage device 12 . The interface 14 may take the form of, for example, an internal bus, SCSI or FiberChannel interface. The SCSI commands may have bespoke data control protocols written into them in order to identify data, data types or data sets which require time-stamping. The data buffer 16 maintains a steady and consistent data transfer rate to the controller 18 . The buffer 16 is typically a piece of memory. The secure controller 18 controls the formatting and preparation of data prior to their recording on the media 22 a , 22 b , 22 c . This can include blocking and compression of the data. The data passed to the controller 18 will typically have a flag set which identifies it as requiring time-stamping or not. The controller 18 then either filters out data flagged “time-stamp me” and passes only (or substantially only) the data with the flag set to ‘timestamp’ to the trusted clock module 20 for time-stamping, or it sends all of the data to the trusted clock which only time-stamps flagged data. The controller 18 may also control the trusted clock 20 . Control logic for the controller 18 may be protected by a separate trust mechanism. This may allow the veracity and/or origin of the logic to be checked and may aid in the detection of downloaded fake control logic. The trusted clock module 20 timestamps and digitally signs the data in a conventional manner, for example using DSA, and passes the data back to the controller 20 , along with the signature. As will be appreciated, the data could be a digest or signature of a larger set of data. The controller 18 contains a checking routine to confirm that the time-stamping is successful. If it is not correctly time-stamped the data is passed back to the trusted clock module 20 for retime-stamping. The controller 18 writes the data timestamp and signature to storage media 22 a , 22 b , 22 c , either in a single block or in a fragmented form. If it is written in a fragmented form, there must be data control logic provided in order to locate the fragments. A public key 24 which, corresponds to the private key used in the digital signing of the data is placed on a network 26 . A recipient of the data can obtain the public key 24 from the network 26 or it can be sent to them either via E-mail or on media. It will be appreciated that the public key need not be ‘published’ but may be retained by the author of the data for their own use, or disseminated to a restricted group of people/entities. The trusted clock module 20 is typically hardwired into the storage device 12 in order to reduce the likelihood of tampering and bogus insertions of clocks into devices. The clock module 20 may be made tamperproof and/or tamper evident by any convenient method (for example it may be encased in resin or other suitable material to prevent/indicate attempts to access it physically). It is recommended that the trusted clock 20 is certified by a trusted CA, but this is not essential. Other ways of having a trusted clock exist (e.g. an encapsulated clock which cannot be altered and can only output the date and time). Provision may made for the replacement of the trusted clock 20 at the expiry of the certificate (e.g. or plug in/out clock module), or authorised service personnel may be capable of removing an encapsulated hardwired clock and replacing it with another, possibly requiring security access codes to disable anti-forgery protection logic. Alternatively it may be possible to upload a new certificate into the clock. Provision may be made for the correction of drift of the trusted clock. For example, the clock may be arranged to synchronise itself with a trusted time signal periodically (e.g. with a satellite clock signal). An alternative to the hardwiring of the clock module 20 is the use of a removable clock module, for example an insertable plug in-plug out cards containing the clock module. This increases the risk of tampering but has the advantage of ease of maintenance and replaceability upon the expiry of a certificate period for a particular clock module. The storage device 13 may be a disc drive, or a tape drive, having no general purpose computing ability, and not being programmable for tasks other than storing and/or retrieving data (with time-stamping and possibly signature generation facilities). Alternatively, whilst still having functionality limited to being essentially a data storage device, it may be more complex such as an array of linked memory stores. FIG. 4 is a flow diagram of a method of time-stamping of data. Data enters a storage device (Step 50 ) and is passed to the controller (Step 52 ). The controller examines the data to see if a flag is present, or if a flag has been set in the command sequence for time-stamping of the data, or if the controller has been configured for time-stamping (Step 54 ). If the flag is not set to time-stamp the data it is written to storage media (Step 56 ). If the flag is set to time-stamp the data it is passed to the time-stamping module (Step 58 ). The data is time-stamped (Step 60 ) and a digital signature effectively scaling the digital time-stamp to the data content, is applied (Step 62 ). A public key corresponding to this signature process can be placed on a network (Step 62 a ), e-mailed to a recipient of the data (Step 62 b ) or stored on media and mailed to a recipient of the data (Step 62 c ). Alternatively, the public key can be recorded manually, not published at all, or published at any stage of the process. The data timestamp and signature are then passed back to the controller (Step 64 ) and the time-stamping process is verified (Step 66 ). The data, time-stamp, and signature are then written to media (Step 68 ). The coupling of the time-stamping features with a storage device ensures that data can always be securely written by this device and does not depend upon the application hosting server to provide secure data management. This is particularly useful in storage architectures which physically and logically separate storage systems from application servers, e.g. storage area networks and network attached storage devices. All data written by the storage device can be content integrity checked and date/time of creation verified at a later date by decrypting and validation of the related signed time-stamp. As can be seen from FIG. 5 , the present invention can reduce network traffic by removing the need to pass time-stamped data back across the network as it is time-stamped at the point at which it is stored. FIG. 5 shows a data originator 80 (e.g. computer, such as PC) connected to the Internet 81 via public telecommunications 82 . Data to be time-stamped, signed and stored by a trusted clock data storage device is transmitted via public telecommunications 83 or 84 to a data storage device 85 or 86 . In case of storage device 85 , the trusted clock, signing capability, and physical data store are all in one physical device, device 85 , and the data is time-stamped signed and stored in device 85 . In the case of device 86 , the trusted clock and signing unit are in one physical box 87 and the memory is in another 88 , or the memory may even be distributed memory 89 in a local network (not back out on the internet). This memory could be disc or tape-based, or chip based. Of course, whilst the time-stamping and signing can be performed in the same “box”, e.g. box 87 , the signing could be in a different physical unit than the time-stamping, either in its own unit, or in the memory unit (still not requiring further access to the internet). Data need only be passed to the time-stamping device and need not be passed back over the network once time-stamped for storage as the time-stamper and storage device (assembly, apparatus or system) are the same. If the network is set up exclusively for the purpose of time-stamping network traffic can be halved. If it is a general purpose network the network traffic associated with time-stamping can still be significantly reduced. FIG. 6 shows a data storage device 90 having an interface I, a buffer 91 , a trusted clock time-stamper 92 , a controller 93 , a signer 94 , and a memory store 95 . The controller 93 receives data from the buffer, decides what part of the data is to be time-stamped and sends that to the trusted clock 92 and receives back time-stamped data. The controller then sends the time-stamped data to the signer which signs it (creates a digest and encrypts the digest to create a signature). The signer then sends the signed time-stamped data back to the controller which sends it to memory 95 for storage. In modified versions the signer could send the signed time-stamped data to the memory 95 without going through the controller. The clock 92 could send time-stamped data straight to the signer without going through the controller. It will be appreciated that the controller may send all data to the clock for time-stamping, or just some data, e.g. selected types of data/selected parts of data. The time-stamper may stamp all data that it receives, or only some of the data that it receives. Data that is not time-stamped may or may not be recorded to memory. Instead of the signing happening in the clock unit itself, it could occur externally of the clock unit, but still within the data storage device. It will be appreciated that having a trusted clock attached to the data memory store provides the shortest path post-time-stamping/signing, which provides the least opportunity for attack on the integrity of the data and/or timestamp, and the least opportunity for breakdowns or bottlenecks in external telecommunication systems to hinder the time-stamping and storage operation. Problems with congested networks hindering acquisition of a timestamp are similarly reduced if, once received by the data storage system, the data does not have to go back out on an external network (e.g. the internet) for time-stamping and signing. Similarly, once time-stamped the data does not have to be subjected to Internet congestion/transmission problems before it is stored. In some embodiments the trusted clock may be a device with a resonating crystal specifically intended for timekeeping. In other devices the clock may be a software clock, which may make use of the clock-speed of a processor chip. In either case, correction for drift of the clock may be possible, for example synchronisation with an external clock signal (e.g. another trusted clock), possibly by wireless communication, possibly by wired (e.g. temporarily wired) connection.