WO1999037054A1 - Procede de stockage de donnees et appareil s'y rapportant - Google Patents

Procede de stockage de donnees et appareil s'y rapportant Download PDF

Info

Publication number
WO1999037054A1
WO1999037054A1 PCT/SG1998/000003 SG9800003W WO9937054A1 WO 1999037054 A1 WO1999037054 A1 WO 1999037054A1 SG 9800003 W SG9800003 W SG 9800003W WO 9937054 A1 WO9937054 A1 WO 9937054A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
depository
valuable
data item
digital
Prior art date
Application number
PCT/SG1998/000003
Other languages
English (en)
Inventor
Jian Hu
Feng Bao
Huije Deng
Original Assignee
Kent Ridge Digital Labs
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kent Ridge Digital Labs filed Critical Kent Ridge Digital Labs
Priority to PCT/SG1998/000003 priority Critical patent/WO1999037054A1/fr
Priority to AU62364/98A priority patent/AU6236498A/en
Priority to GB0014589A priority patent/GB2349964B/en
Publication of WO1999037054A1 publication Critical patent/WO1999037054A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum

Definitions

  • the present invention relates to the field of data processing, and more particularly, but not exclusively, to a method and apparatus for implementing a system which is able to provide digital storage services for public or corporate users.
  • a user's digital information is commonly stored in the user's computer or in a networked file server.
  • Digital information is inevitably in digital format. The information is easy to tamper with, and the modifications need not leave any trace on the physical medium. In many situations it is necessary for a user to verify that the information retrieved is indeed what was stored in the first place and any modification to the information by system faults or malicious process can be detected.
  • the second problem is low reliability. A hard disk or floppy disk may crash, resulting in irreversible loss of data.
  • a networked file server provides higher reliability than a local hard disk but loss of data is not uncommon. Moreover, such servers lack adequate security protection and are not easily accessible to public users.
  • the third problem with the current technology of storing information is that it has little confidentiality protection.
  • a digital data depository for storing digital data items for a user comprising: data storage means; a user account associated with the user; means for communication with the user; means for authentication of the user with the depository; means for establishing a digital data transaction session in which the user is able to instruct storage or retrieval of a digital data item in association with the user's account; means for encoding the data item into a plurality of parts, the parts being separately stored in the storage means;and means for decoding the encoded data item.
  • a method of storing digital data items for a user comprising the steps of: providing a user account associated with the user; authenticating the identity of the user; receiving a digital data item and an instruction from the user for the item to be stored in association with the user's account; and encoding the data item into a plurality of parts and storing the parts separately.
  • a method of protecting digital data comprising: providing a data depository in which digital data may be stored electronically; providing for registration of users of the data depository, each user having an account with the depository; in response to a request from a user, opening a transaction session with the user in which the user and the depository authenticate each other and performing a transaction instructed by the user in respect of a digital data item, the transaction being selected by the user from a plurality of available transactions including storage of the item in or retrieval of the item from the depository.
  • the described embodiment of the present invention discloses a method for implementing a digital valuables depository system, for public or corporate users to store and to retrieve precious digital information.
  • the described embodiment is the electronic analogy to the physical safe boxes provided by banks whereby customers can keep their precious belongings.
  • SP Service Provider
  • the User To make use of the service, the User first registers with the SP to open an account. The User can then deposit digital valuables into, retrieve and delete them from its account, all being carried out in an authentic and secure manner.
  • the SP ensures high reliability in storing users' digital valuables.
  • the SP first encodes each valuable into N parts based on an encoding algorithm, and then stores the N parts into one or more data storage devices.
  • the SP reads the N parts from corresponding storage devices, and recovers the valuable from the N parts based on a decoding algorithm.
  • the encoding and decoding algorithms are chosen such that the original valuable can be recovered correctly even if some of the N parts are lost or corrupted.
  • the system periodically checks the N parts of every stored valuables and recovers/corrects lost/corrupted parts when they are detected.
  • FIG. 1 is a schematic diagram of a data storage system, being an embodiment of the invention.
  • FIG. 2 shows a possible data structure of the User Account maintained by the Service Provider (SP) in the preferred embodiment of the present invention.
  • SP Service Provider
  • FIG. 3 shows the steps to allow the User accessing his account in the preferred embodiment of the present invention.
  • FIG. 4(a) illustrates a possible logical structure of the Transaction Request message of type Valuable Storage (VS_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 4(b) illustrates a possible logical structure of the Transaction Request message of type Valuable Copy (VC_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 4(c) illustrates a possible logical structure of the Transaction Request message of type Valuable Deletion (VD_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 4(d) illustrates a possible logical structure of the Transaction Request message of type Valuable Retrieval (VR_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 4(e) illustrates a possible logical structure of the Transaction Request message of type Account Status Report (ASR_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 4(f) illustrates a possible logical structure of the Transaction Request message of type Session Close (SC_Req) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(a) illustrates a possible logical structure of the Transaction Response message of type Valuable Storage (VS_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(b) illustrates a possible logical structure of the Transaction Response message of type Valuable Copy (VC_Resp) in accordance with preferred embodiment of the present invention.
  • FIG. 5(c) illustrates a possible logical structure of the Transaction Response message of type Valuable Deletion (VD_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(d) illustrates a possible logical structure of the Transaction Response message of type Valuable Retrieval (VR_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(e) illustrates a possible logical structure of the Transaction Response message of type Account Status Report (ASR_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(f) illustrates a possible logical structure of the Transaction Response message of type Session Close (SC_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 5(g) illustrates a possible logical structure of the Transaction Response message of type Error (ERR_Resp) in accordance with the preferred embodiment of the present invention.
  • FIG. 6 shows the flow diagram of a Transaction Response Program (TRP) used in the preferred embodiment of the present invention.
  • TRP Transaction Response Program
  • FIG. 7 illustrates the flow diagram of the first Valuable Dispersal Program (VDP) used in the preferred embodiment of the present invention.
  • VDP Valuable Dispersal Program
  • FIG. 8 shows the flow diagram of the first Valuable Recovery Program (VRP) used in the preferred embodiment of the present invention.
  • VRP Valuable Recovery Program
  • FIG. 9 illustrates the flow diagram of the second Valuable Dispersal Program (VDP) used in the preferred embodiment of the present invention.
  • VDP Valuable Dispersal Program
  • FIG. 10 shows the flow diagram of the second Valuable Recovery Program (VRP) used in the preferred embodiment of the present invention.
  • VRP Valuable Recovery Program
  • FIG. 11 shows the flow diagram of the first Valuable Checking and Correction Program (VCCP) used in the preferred embodiment of the present invention.
  • VCCP Valuable Checking and Correction Program
  • FIG. 12 shows the flow diagram of the second Valuable Checking and Correction Program (VCCP) used in the preferred embodiment of the present invention.
  • VCCP Valuable Checking and Correction Program
  • Digital Safe Methods for implementing a digital data depository system,hereinafter referred to as Digital Safe, are described.
  • the system is an electronic analogy to the physical safe boxes provided by banks whereby customers can keep their precious belongings.
  • numerous specific details are set forth such as logical structures of digital information and program steps, etc. in order to provide a thorough understanding of the present invention. It will be obvious to one skilled in the art that the present invention may be practised without these specific details.
  • the manipulations performed are often referred to in terms such as adding or comparing, which are commonly associated with the mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable.
  • the operations are machine operations.
  • Useful machines for performing the operations of the present invention include general purpose digital computers or similar devices such as digital signal processors.
  • the embodiment of the present invention to be described relates to method steps for secure and reliably storing users' digital valuables into and then subsequently retrieving them from a data depository system maintained and operated upon by a service provider.
  • the embodiment of the present invention also relates to an apparatus for performing these operations.
  • This apparatus may be specially constructed for the required purpose or it may comprise general purpose computers as selectively activated or reconfigured by a computer program stored in the computers.
  • the algorithms presented herein are not inherently related to any particular computer or other apparatus.
  • various general purpose machines may be used with programs written in accordance with the teachings herein, or it may prove more convenient to construct specialized apparatus such as digital signal processor to perform the required method steps. The required structure for a variety of these machines would appear from the description given below.
  • FIG. 1 A general model of the Digital Safe system is shown in FIG. 1. in which the Service Provider (SP) 10 provides data depository services to User 30 via a transmission channel 20.
  • the SP system is responsible for storing and retrieving the User's digital valuables in a secure, reliable, and authenticated manner.
  • a digital valuable, or valuable for short has an unique identifier and is a self-contained entity. There can be various types of valuables including but not restricted in form to text, graphics, animation, video, audio, software, or any combination thereof.
  • the transmission channel 20 represents the means and more specifically the media through which communication messages are exchanged between the SP 10 and the User 30. Such messages include the User's requests to the SP over paths 25 and 15 and the SP's responses to the User over paths 15 and 25.
  • the transmission channel 20 includes but is not limited to any communication means or media such as computer networks, radio links, satellite links, diskettes or other storage medium. It should be understood by one skilled in the art that the term User is interchangeable with any user of information.
  • the described embodiment teaches methods for securely and reliably storing Users' valuables into and then retrieving them from the User's account maintained by the SP. These methods will be described with reference to specific steps of manipulating information. For one skilled in the art, it is obvious that some of these steps shall be best automated by, for example, implementing them as a special purpose software, which is usually called a server, running on general purpose computers. It is clear that an information provider could simultaneously initiate multiple executions of the server to serve multiple end users. It is also clear that there may exist multiple SPs. For example, there may be one SP per organization or per district.
  • the User 30 registers itself to the SP.
  • the User authenticates itself to the SP by whatever means as required by the SP.
  • the User agrees to the terms of a service contract.
  • a service contract contains at a minimum the identities, addresses of both the User and the SP, and the types of services to be provided by the SP. It may contain the public keys of the User and the SP, respectively. These keys are selected by the respective party based on certain public-key cryptosystems (PKCs). It may contain secret keys shared by the Users and the SP.
  • PLCs public-key cryptosystems
  • the Digital Safe system relies on cryptographic protocols for mutual authentication between the User and the SP and for protecting the confidentiality and integrity of the User's valuables. Such cryptographic protocols require the User to possess cryptographic keys or secrets to operate.
  • the contract may also specify the procedures for the User to recover lost cryptographic keys or secrets.
  • MAC Message authentication code
  • a MAC of a message can be generated using a symmetric key cryptosystem with the message and a secret value as inputs or using a one-way hash function with the message and a secret value as inputs. Since both digital signature and MAC are used for message integrity protection and authentication, we will refer them as Integrity Check (IC).
  • Integrity Check IC
  • PKC symmetric key cryptosystem, generation and verification of digital signature, one-way hash functions, generation and verification of MAC, and public key certificate, see D. E. R. Denning, Cryptography and Data Security, Addition-Wesley, Reading, MA, 1983; W.
  • the SP sets up an account for the User.
  • the User's account is allocated a fixed data storage quota and time interval (which may be extended or reduced at the User's request) and the service charge might be at a flat rate.
  • the second type called flexible-rate account
  • the User's account has no fixed data storage quota and the User is charged by usage.
  • the User's account might be represented by a data structure shown FIG. 2, which includes a unique Account number (Acc_No) 50, the User's identity (U_ID) 52, contact information 54, optionally public keys or public key certificates 56, and information items 58 related to valuables stored in the account.
  • Possible information items 58 are valuable identity (V_ID), type, size, time of submission, a protection flag (P_FLAG), an optional storage interval for flexible-rate account and pointers to locations where the N parts of the valuable are stored.
  • the P_FLAG takes two possible values, Encryption_Required and Encryption_Not_Required. If P_FLAG is set to Encryption_Required, then the valuable is encrypted by the SP and a pointer to the decryption key is kept in the account for each SP encrypted valuable. If P_FLAG is set to Encryption_Not_Required, then the valuable is not encrypted by the SP.
  • the information items related to stored valuables will be empty initially and will be updated every time the User updates its account or when a valuable's storage interval expires. It should be noted that all the items in the User's account can be made visible to the User except the pointers to decryption keys and the pointers to storage locations, which are only accessible to and modifiable by the SP.
  • the Digital Safe services provided by the SP 10 to the User 30 include Valuable Storage (VS), Valuable Copy (VC), Valuable Retrieval (VR), Valuable Deletion (VD), and Account Status Report (ASR).
  • VS Valuable Storage
  • VC Valuable Copy
  • VR Valuable Retrieval
  • VD Valuable Deletion
  • ASR Account Status Report
  • the VS service lets the User store new valuables in its account
  • the VC service allows the User to get copies of its previously stored valuables from its account
  • the VD service lets the User remove one or more valuables from its account
  • the VR service permits the User to get copies of previously stored valuables and at the same time delete those valuables from his account
  • ASR service provides the User with its most recent account status report.
  • FIG. 3 shows the steps a user follows in accessing its account in the preferred embodiment of the present invention.
  • the User and the SP starts a transaction session by running a mutual authentication and a session key exchange protocol.
  • the User 10 prepares an Open Request (O_Req) message and sends the O_Req to the SP in step 100.
  • the O_Req message is used to initiate the communications between the User and the SP, and more importantly, to authenticate the User to the SP.
  • the O_Req contains at least the User's account number Acc_No 50 and/or identity U_ID 52. It is integrity protected by an IC ( i. e., either the User's digital signature or a MAC) which can be verified by the SP.
  • IC i. e., either the User's digital signature or a MAC
  • the SP Upon receiving the O_Req, the SP verifies its validity in step 110. If it is not valid, an alert signal is sent to the User and the SP in step 120. If it is valid, the SP generates an Open Response (O_Resp) message, sends it to the User and opens a session with the User in step 130.
  • O_Resp Open Response
  • the O_Resp is used to authenticate the SP to the User. This is integrity protected by an IC (i. e., either the SP's signature or a MAC) which can be verified by the User.
  • O_Resp the User checks its validity in step 140. An alert signal is sent to the User and/or the SP in step 150 if the Response is not valid; otherwise, the User proceeds to step 160.
  • O_Req and O_Resp are mutual authentication of the User and the SP, to negotiate a unique session identifier to bind the User's transaction with his account, and to negotiate session keys for encrypting and integrity protecting the follow on message exchanges during the entire session if the communication path between the User and the SP is not secure.
  • There are many authentication and key distribution protocols in the literature see, for example, C. Kaufman, R. Perlman, and M. Speciner, Network Security - Private Communication in A Public World, PTR Prentice Hall, Englewood Cliffs, NJ. 1995) which fulfil these requirements. Such protocols can be used in place of O_Req and O_Resp.
  • T_Req Transaction Request
  • VS_Req Valuable Storage Request
  • VD_Req Valuable Copy Request
  • VR_Req Valuable Retrieval Request
  • ASR_Req Account Status Report Request
  • SC_Req Session Close Request
  • FIG. 4(a) shows the structure of VS_Req.
  • This logical structure comprises a session identifier (S_ID) 170 which was negotiated during steps 100 and 110 in FIG. 3 and is used here to identify uniquely the present session, a transaction type field VS_Req 175 which identifies the type of T_Req as Valuable Storage, a valuable identifier V_ID 180 which shows the identity of the submitted valuable, a field P_FLAG 182 which takes two possible values Encryption_Required and Encryption_Not_Required.
  • S_ID session identifier
  • V_ID 180 which shows the identity of the submitted valuable
  • P_FLAG 182 which takes two possible values Encryption_Required and Encryption_Not_Required.
  • the EncryptionJRequired value indicates that the User's valuable be encrypted by the SP before it is stored while the Encryption_Not_Required value indicates that the User's valuable be not encrypted by the SP before it is stored.
  • the VS_Req message also contains a field V_By 185 which is the submitted valuable body, an optional field V_SI 188 which specifies the storage time interval of the submitted valuable (note that this field is not needed for flat-rate account), a freshness identifier F_ID_U 190 which guarantees that the message is fresh or in sequence, and a message IC field IC_U 195.
  • the V_By 185 may be in plaintext or in ciphertext. The latter is preferred if the User wants to keep the valuable confidential only to itself.
  • the V_By contains the User's digital signature which can be used by either the User, or the SP, or an independent judge to verify the authenticity of the valuable. To simplify the presentation, only one V_ID and one V_By are shown here. In general, the message in FIG. 4(a) may contain multiple V_ID and multiple V_By fields.
  • FIG. 4(b) depicts the structure of VC_Req. It comprises the S_ID 170, a transaction type field VC_Req 205 which identifies the type of T_Req as Valuable Copy, a valuable identifier V_ID 210 which shows the identity of the valuable to be copied, a freshness identifier FJD -J 215 and a message IC field IC_U 220.
  • VD_Req and VR_Req Possible logical structures of VD_Req and VR_Req are given in FIG. 4(c) and FIG. 4(d), respectively.
  • the field VD_Req 225 indicates the type of T_Req as Valuable Deletion and the field V_ID 230 shows the identity of the valuable to be deleted.
  • the field VR_Req 245 indicates the type of the T_Req as Valuable Retrieval and the field V_ID 250 identifies the name of the valuable to be retrieved.
  • each message in FIG. 4(b) - 4(d) may contain multiple V_IDs.
  • FIG. 4(e) and FIG. 4(f) show the structures of ASR_Req and SC_Req, respectively.
  • the field ASR_Req 265 indicates the type of T_Req as Account Status Report
  • the field ASR_Option 270 specifies the format of the status report. Possible values of ASR_Option are FULL (in which case the SP will send the User a full version report, as specified in FIG. 2) and SHORT (in which case the SP will send the User a User selectable short version report).
  • the SC_Req 285 indicates that the T_Req is of type Session Close.
  • the F_ID_U and the IC_U fields are optional. They should be present if the communication path between the User and the SP is not integrity protected.
  • the F_ID_U may be a timestamp, a sequence number, or a nonce (a non-repeating random number generated by SP and sent to the User in advance).
  • the IC_U is computed over the entire message; it may be the User's digital signature generated using its private key or it may be a MAC generated using a secret key which is shared between the User and the SP.
  • the User's digital signature must be used for the IC_U field whenever non-repudiation of origin of the T_Req messages is a requirement. Referring to FIG.
  • T_Resp Transaction Response
  • TRP Transaction Response Program
  • VS_Resp Valuable Storage Response
  • VD_Resp Valuable Copy Response
  • VD_Resp Valuable Deletion Response
  • VR_Resp Valuable Retrieval Response
  • ASR_Resp Account Status Report Response
  • SC_Resp Session Close Response
  • ERR_Resp Error Response
  • FIG. 5(a) - 5(g) show possible logical structures of the seven Transaction Response types in accordance with the preferred embodiment of the present invention.
  • FIG. 5(a) is the structure of VS_Resp. It comprises a session identifier (S_ID) 170 which was negotiated during steps 100 and 110 in FIG. 3 and is used here to uniquely identify the present session, a field VS_Resp 300 which indicates the type of T_Resp as Valuable Storage, V_ID 180 taken from FIG. 4(a), a field VS_ACK 305 which indicates the success or failure of the transaction processing, a freshness identifier F_ID_SP 310 which guarantees that the message is fresh or in sequence, and a message IC field IC_SP 315.
  • S_ID session identifier
  • F_ID_SP freshness identifier
  • FIG. 5(b) is the structure of VC_Resp. It consists of S_ID 170, a field VC_Resp 320 which identifies the T_Resp as type Valuable Copy, V_ID 210 taken from FIG. 4(b), the copied valuable V_By 325 as specified by V_ID, a field VC_ACK 327 indicating the success or failure of the transaction processing, the fields F_ID_SP 330 and IC_SP 335.
  • FIG. 5(c) is the structure of VD_Resp. It consists of S_ID 170, a field VD_Resp 340 which identifies the T_Res ⁇ as type Valuable Deletion, V_ID 230 taken from FIG. 4(c), a field VD_ACK 342 indicating the success or failure of the transaction processing, the fields F_ID_SP 345 and IC_SP 350.
  • FIG. 5(d) is the structure of VR_Resp. It consists of S_ID 170, a field VR_Res ⁇ 355 which identifies the T_Resp as type Valuable Retrieval, V_ID 250 taken from FIG. 4(d), the retrieved valuable V_By 360 as specified by V_ID, a field VR_ACK 362 showing the success or failure of the transaction processing, the fields F_ID_SP 365 and IC_SP 370.
  • FIG. 5(e) is the structure of ARS_Resp. It comprises S D 170, a field ASR_Resp 375 which identifies the T_Resp as type Account Status Report, a field ASR_Report 380 with its format as specified by ASR_Option 270 in FIG. 4(e), a ASR_ACK field 382 indicating the success or failure of the transaction processing, the fields F_ID_SP 385 and IC_SP 390.
  • FIG. 5(f) is the structure of SC_Resp. It consists of S_ID 170, a field SC_Resp 395 which identifies the T_Resp as type Session Close, a field CS_ACK 398 indicating the success or failure of the transaction processing, the fields F_ID_SP 400 and IC_SP 405.
  • FIG. 5(g) is the structure of ERR_Res ⁇ . It consists of S_ID 170, a field ERR_Resp 410 which identifies the T_Resp as type ERROR, a field T_Req_Type 415, a field ERR_Status 420, the fields F_ID_SP 425 and IC_SP 430.
  • T_Req_Type indicates the type of T_Req with which the ERROR message is associated with. Possible values of T_Req_Type are VS_Req, VC_Req, VD_Req, VR_Req, ASR_Req, and SC_Req.
  • ERR_Status shows the type of errors which takes possible values such as "Request Not Verified" and "Request Not Permitted".
  • the F_ID_SP and the IC_SP fields are optional. They should be present if the communication path between the SP and the User is not integrity protected.
  • the F_ID_SP may be a timestamp, a sequence number, or a nonce (i. e., a non-repeating random number generated by the User and sent to the SP before hand).
  • the IC SP is computed over the entire message; it may be the SP's digital signature generated using its private key or it may be a MAC generated using a secret key shared between the SP and the User. The former must be used if non-repudiation of origin of T_Resp messages are required.
  • the SP sends the T Resp to the User in step 1000.
  • the T_Resp sent in step 1000 by the SP is received at the User side in step 1020.
  • the User first verifies if T_Resp is valid in 1030, including verifying the freshness of the freshness identifier F_ID_SP and the validity of the integrity check IC_SP. If the answer is "No", an alert signal is sent to the User and/or the SP in step 1040 and the User/SP will take actions accordingly. Assuming that the output of step 1030 is "Yes”, the User then checks to see l o if the received T_Resp is of type SC_Resp. If yes, the current session is closed; otherwise, it accepts and outputs the results of the T_Resp message in step 1055 and then goes back to step 160.
  • FIG. 6 shows the flow diagram of a Transaction Response Program (TRP) used in the preferred embodiment of the present invention.
  • TRP Transaction Response Program
  • the T_Req received in step 490 in FIG.3 is first checked for its validity in step 520, including checking the validities of the freshness identifier F_ID_U and the integrity check IC_U, as well as checking if the requested operation in T_Req is permitted. If the T_Req is not valid, a T_Resp of type ERR_Resp is formed in step 530, where the format of the ERR_Resp is as specified in FIG. 5(g). Assuming that T_Req passes the checking in step 520, it is next inspected in step 540 to see if it is of type SC_Req.
  • ERR_Resp Transaction Response Program
  • the TRP closes the current session and prepares a T_Resp of type SC_Resp in step 550 according to the format of the T_Resp given in FIG. 5(f). Assuming that the outcome in step 540 is "No", the T_Req is checked in step 560 to see if it is of type VS_Req. If yes, the TRP first processes and stores the submitted valuable using a Valuable Dispersal Program (VDP), updates the User's account (i.
  • VDP Valuable Dispersal Program
  • the TRP first recovers the requested valuable using a Valuable Recovery Program (VRP) and then prepares a T_Resp of type VC_Resp in 590, where the format of VC_Resp is according to FIG. 5(b). Assuming that step 580 yields "No", the T_Req is next checked in step 600 to see if it is of type VD_Req, if the answer is "Yes", the TRP first deletes the valuable specified in T_Req and then prepares a T_Resp of type VD_Resp in step 610 according to the format as given in FIG. 5(c).
  • VRP Valuable Recovery Program
  • step 620 the T_Resp is next checked in step 620 for type VR_Req. If yes, the TRP first recovers the requested valuable using VRP, delete the valuable from the User's account, and prepares a T_Resp of type VR_Resp according to the format of FIG. 5(d), all being performed in step 630. If the output of step 620 is "No", the T_Req must be of type ASR_Req. In this case, the TRP prepares a T_Req of type ASR_Req, with its format as given in FIG. 5(e).
  • T_Resp messages prepared in steps 530, 550, 570, 590, 610, 630, and 640 are sent to the User in step 1000 in FIG. 3.
  • the executions of the steps 540, 560, 580, 600, 620, and 640 do not have to follow the order given above; they may be carried out in any order according to the preference if the system designer.
  • FIG. 7 illustrates the flow diagram of the first Valuable Dispersal Program (VDP) used in the preferred embodiment of the present invention.
  • VDP Valuable Dispersal Program
  • the valuable to be processed by the VDP program has the valuable identifier V_ID 180 and valuable body V_By 185 as specified by the VS_Req message shown in FIG. 4(a).
  • the valuable contains the User's digital signature which can be checked by the User and the SP to verify its authenticity.
  • the basic function of VDP is to transfer a submitted valuable into N parts based on an (N, K) error-control code C with symbols over Galois field GF(2 m ), where m is a positive integer.
  • N, K error-control code
  • step 700 the User's digital signature on the valuable is first checked in step 700. If it is valid, the VDP proceeds to step 705; otherwise it goes to step 530 in Fig. 6. In step 705, the VDP checks if the P_FLAG 182 field of the VS_Req message is set to Encry ⁇ tion_Required. If "No", the program proceeds to step 715; otherwise, the valuable is encrypted under a cryptographic key in step 710.
  • FIG. 8 shows the flow diagram of the first Valuable Recovery Program (VRP) which works in conjunction with the first VDP in the preferred embodiment of the present invention.
  • VRP Valuable Recovery Program
  • step 770 the VRP reads the corresponding P_FLAG from the User's account and checks if it equals EncryptionJRequired. If "No", the program produces the required valuable (which is the output of step 760) in step 780; if "Yes", the program proceeds to step 775 where it decrypts the output of step 760 using the appropriate decryption key. The result of step 775 is the required valuable which is output in step 780.
  • d denote the minimum Hamming distance of the (N, K) code C.
  • maximum- distance codes such as the Reed-Solomon codes
  • their minimum Hamming distance d N - K + 1. Therefore, given K, an N can almost be selected, such that the probability that a valuable cannot be recovered is smaller than a pre-determined threshold.
  • FIG. 9 illustrates the flow diagram of the second Valuable Dispersal Program (VDP) used in the preferred embodiment of the present invention.
  • VDP Valuable Dispersal Program
  • the valuable to be processed by the VDP program has the valuable identifier V_ID 180 and valuable body V_By 185 as specified by the VS_Req message shown in FIG. 4(a).
  • the valuable contains the User's digital signature which can be checked by the User and the SP to verify its authenticity.
  • the basic function of VDP is to transfer a submitted valuable into N parts based on an (N, K) error-control code C with symbols over Galois field GF(2 m ), where m is a positive integer.
  • the User's digital signature on the valuable is first checked in step 800.
  • an integrity check (as discussed under "Overall System Setup") IC.
  • FIG. 10 shows the flow diagram of the second Valuable Recovery Program (VRP) which works in conjunction with the second VDP in the preferred embodiment of the present invention.
  • VRP Valuable Recovery Program
  • the N-tuple Y', (y',, y' l2 ... y', ⁇ ) is a codeword corrupted by erasures.
  • step 870 the VRP reads the corresponding P_FLAG from the User's account and checks if it equals EncryptionJRequired. If "No", the program produces the required valuable (which is the output of step 865) in step 880; if "Yes”, the program proceeds to step 875 where it decrypts the output of step 865 using the appropriate decryption key. The result of step 875 is the required valuable which is output in step 880.
  • DCCP Data Checking and Correction Program
  • the first DCCP works in conjunction with the first VDP in section 4. Its flow diagram is shown in FIG. 11.
  • Step 910 checks if all the q decoding operations in step 905 are successful. If not, an alarm is raised in step 915 and the program goes to step 925; if yes, the DCCP proceeds to step 920.
  • the DCCP checks to see if there are more stored valuables need to be checked. If not, the program terminates; if yes, it gets the D_ID of the valuable to be checked in step 930 and goes back to step 900.
  • the second DCCP works in conjunction with the second VDP in section 5 and its flow diagram is shown in FIG. 12.
  • step 975 If yes, the DCCP goes to step 975; if not, the DCCP proceeds to step 950 where the Z' j is marked as a q-tuple of "erasures" if it is not found or if it fails to pass the integrity check.
  • Step 955 checks to see if the number of erased Z' j S is less d, the minimum Hamming distance of the (N, K) code C. If not, the DCCP raises an alarm in step 960 and then goes to step 975; if yes, the program proceeds to step 965.
  • step 975 the DCCP checks if there are any more valuables need to be checked. If not, the program terminates and if yes, it fetches D_ID of the valuable to be checked in step 980 and then goes back to step 945.
  • the User of the Digital Safe system needs to keep two sets of secret values, one for authentication to the SP in order to access its account and the other one for encrypting its valuables before submitting them to the SP.
  • the former set of secret values are referred to as User Authentication Secret Values (UASVs) and the latter set of secret values are referred to as Valuable Protection Secret Values (VPSVs).
  • USVs User Authentication Secret Values
  • VPSVs Valuable Protection Secret Values
  • Examples of such secret values are private keys in public key cryptosystems and secret keys in symmetric key cryptosystems. All the secret values must be kept by the User in a secret and secure manner.
  • An example of keeping a VPSV is to encrypt a valuable under the VPSV, encrypt the VPSV under a master key, and attach the encrypted VPSV with the valuable.
  • Loss of the UASVs prevents the User from accessing its account on-line.
  • the User approaches pre-determined Key Escrow Agents to recover UASVs if UASVs are escrowed by such agents.
  • the User will have to authenticate itself to the SP by other means (such as using paper documents) and upon authentication, the User and the SP separately or jointly establishing a new set of UASVs to replace the lost ones.
  • the User from that point onwards uses the new UASVs to authenticate itself in order to access its account.
  • Loss of VPSVs prevents the User from decrypting its encrypted data or verifying the authenticity of the retrieved/copied valuables from its account. To prevent this from happening, the User should keep multiple copies of the VPSVs or make use of the key recovery services provided by a key escrow system. In the event of the User losing its VPSVs, the User approaches Key Escrow Agents to recover lost VPSVs. If the lost VPSVs are not escrowed, then valuables encrypted by the lost VPSVs will be lost too.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Cette invention concerne un procédé et un appareil qui permettent de mettre en oeuvre un système de dépôt de valeurs numériques dans lequel des utilisateurs publics ou des entreprises peuvent stocker ou retirer de manière électronique des informations numériques de valeur. Cet appareil est l'équivalent électronique des coffres forts physiques que les banques mettent à la disposition de leurs clients afin d'y stocker des articles de valeur. Ce service de dépôt de valeurs numériques est offert par un prestataire de services (PS). Afin d'utiliser ces services, un utilisateur va ouvrir un compte de coffre numérique auprès du PS. L'utilisateur peut alors déposer des valeurs numériques dans son compte ainsi que les en retirer, les copier ou les en effacer, ceci de manière sûre et certifiée. Afin de stocker des valeurs numériques, le PS va d'abord les coder en un nombre de parties N à l'aide d'un algorithme de codage. Le PS va ensuite stocker les N parties dans un ou plusieurs dispositifs de stockage de données. Afin de retirer ou de copier des valeurs numériques précédemment stockées, le PS va lire les N parties dans les dispositifs de stockage correspondants, puis récupérer les valeurs numériques à partir des N parties et à l'aide d'un algorithme de décodage. Les algorithmes de codage et de décodage sont choisis de manière à ce que les valeurs numériques originales puissent être récupérées correctement même si quelques-unes des N parties ont été perdues ou corrompues. Afin d'éviter les erreurs de stockage/l'accumulation de corruptions, le système va vérifier périodiquement les N parties de chacune des valeurs numériques stockées, puis récupérer/corriger le cas échéant les parties qui ont été perdues/corrompues.
PCT/SG1998/000003 1998-01-16 1998-01-16 Procede de stockage de donnees et appareil s'y rapportant WO1999037054A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/SG1998/000003 WO1999037054A1 (fr) 1998-01-16 1998-01-16 Procede de stockage de donnees et appareil s'y rapportant
AU62364/98A AU6236498A (en) 1998-01-16 1998-01-16 A method of data storage and apparatus therefor
GB0014589A GB2349964B (en) 1998-01-16 1998-01-16 A method of data storage and apparatus therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG1998/000003 WO1999037054A1 (fr) 1998-01-16 1998-01-16 Procede de stockage de donnees et appareil s'y rapportant

Publications (1)

Publication Number Publication Date
WO1999037054A1 true WO1999037054A1 (fr) 1999-07-22

Family

ID=20429827

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG1998/000003 WO1999037054A1 (fr) 1998-01-16 1998-01-16 Procede de stockage de donnees et appareil s'y rapportant

Country Status (3)

Country Link
AU (1) AU6236498A (fr)
GB (1) GB2349964B (fr)
WO (1) WO1999037054A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2368162A (en) * 2000-06-12 2002-04-24 Business Information Publicati A secure electronic deposit box with disk space dedicated to each user
EP1257949A1 (fr) * 2000-01-11 2002-11-20 Tso, Inc. Procede et systeme pour la protection des secrets de fabrication
EP1093069A3 (fr) * 1999-10-15 2004-03-03 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
WO2008065342A1 (fr) * 2006-12-01 2008-06-05 David Irvine Cartes de données
WO2008065344A1 (fr) * 2006-12-01 2008-06-05 David Irvine Authentification anonyme
WO2008065351A1 (fr) * 2006-12-01 2008-06-05 David Irvine Encryptage automatique
WO2008065343A1 (fr) * 2006-12-01 2008-06-05 David Irvine Accès partagé à des fichiers privés
WO2008065341A3 (fr) * 2006-12-01 2008-07-17 David Irvine Maidsafe.net
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
US9886558B2 (en) 1999-09-20 2018-02-06 Quintiles Ims Incorporated System and method for analyzing de-identified health care data

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0033833A2 (fr) * 1980-02-11 1981-08-19 International Business Machines Corporation Système pour l'exécution de transactions, procédé de fonctionnement d'un tel système, et terminal destiné à être utilisé dans un tel système
EP0166541A2 (fr) * 1984-06-25 1986-01-02 Kabushiki Kaisha Toshiba Réseau de communications utilisant un dispositif de chiffrage et de déchiffrage
EP0547975A1 (fr) * 1991-12-19 1993-06-23 Bull Cp8 Procédé d'authentification, par un milieu extérieur, d'un objet portatif connecté à ce milieu par l'intermédiaire d'une ligne de transmission, et système pour la mise en oeuvre
EP0561150A2 (fr) * 1992-02-14 1993-09-22 Siemens Aktiengesellschaft Méthode pour réaliser des programmes dans un hôte connecté à un système de communication
EP0582827A2 (fr) * 1992-08-10 1994-02-16 General Instrument Corporation Of Delaware Méthode et appareil pour communiquer de données entrelacées
WO1996002993A2 (fr) * 1994-07-19 1996-02-01 Bankers Trust Company Procede permettant d'utiliser en toute securite des signatures numeriques dans un systeme de chiffrage commercial

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0033833A2 (fr) * 1980-02-11 1981-08-19 International Business Machines Corporation Système pour l'exécution de transactions, procédé de fonctionnement d'un tel système, et terminal destiné à être utilisé dans un tel système
EP0166541A2 (fr) * 1984-06-25 1986-01-02 Kabushiki Kaisha Toshiba Réseau de communications utilisant un dispositif de chiffrage et de déchiffrage
EP0547975A1 (fr) * 1991-12-19 1993-06-23 Bull Cp8 Procédé d'authentification, par un milieu extérieur, d'un objet portatif connecté à ce milieu par l'intermédiaire d'une ligne de transmission, et système pour la mise en oeuvre
EP0561150A2 (fr) * 1992-02-14 1993-09-22 Siemens Aktiengesellschaft Méthode pour réaliser des programmes dans un hôte connecté à un système de communication
EP0582827A2 (fr) * 1992-08-10 1994-02-16 General Instrument Corporation Of Delaware Méthode et appareil pour communiquer de données entrelacées
WO1996002993A2 (fr) * 1994-07-19 1996-02-01 Bankers Trust Company Procede permettant d'utiliser en toute securite des signatures numeriques dans un systeme de chiffrage commercial

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9886558B2 (en) 1999-09-20 2018-02-06 Quintiles Ims Incorporated System and method for analyzing de-identified health care data
EP1793527A3 (fr) * 1999-10-15 2015-01-21 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
EP1093069A3 (fr) * 1999-10-15 2004-03-03 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
EP1772987A2 (fr) * 1999-10-15 2007-04-11 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
EP1793527A2 (fr) * 1999-10-15 2007-06-06 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
EP1772987A3 (fr) * 1999-10-15 2015-01-21 Fujitsu Limited Appareil et méthode pour la gestion de données électroniques originelles
EP1257949A1 (fr) * 2000-01-11 2002-11-20 Tso, Inc. Procede et systeme pour la protection des secrets de fabrication
EP1257949A4 (fr) * 2000-01-11 2005-05-11 Tso Inc Procede et systeme pour la protection des secrets de fabrication
US7441277B2 (en) 2000-06-12 2008-10-21 Bip Solutions Limited Electronic deposit box system
GB2368162A (en) * 2000-06-12 2002-04-24 Business Information Publicati A secure electronic deposit box with disk space dedicated to each user
GB2368162B (en) * 2000-06-12 2004-12-15 Business Information Publicati Electronic deposit box system
WO2008065351A1 (fr) * 2006-12-01 2008-06-05 David Irvine Encryptage automatique
WO2008065343A1 (fr) * 2006-12-01 2008-06-05 David Irvine Accès partagé à des fichiers privés
WO2008065341A3 (fr) * 2006-12-01 2008-07-17 David Irvine Maidsafe.net
WO2008065344A1 (fr) * 2006-12-01 2008-06-05 David Irvine Authentification anonyme
WO2008065342A1 (fr) * 2006-12-01 2008-06-05 David Irvine Cartes de données
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data

Also Published As

Publication number Publication date
AU6236498A (en) 1999-08-02
GB2349964A (en) 2000-11-15
GB2349964B (en) 2002-07-24
GB0014589D0 (en) 2000-08-09

Similar Documents

Publication Publication Date Title
US7421079B2 (en) Method and apparatus for secure key replacement
US10742420B1 (en) Quantum-resistant double signature system
US8559639B2 (en) Method and apparatus for secure cryptographic key generation, certification and use
EP1969762B1 (fr) Systeme de certification et de fractionnement pour remplacer des cles crypthographiques
US5604801A (en) Public key data communications system under control of a portable security device
AP626A (en) Cryptographic system and method with key escrow feature.
US6192472B1 (en) Method and apparatus for the secure distributed storage and retrieval of information
US6161181A (en) Secure electronic transactions using a trusted intermediary
US5956404A (en) Digital signature with auditing bits
US6956950B2 (en) Computer readable medium having a private key encryption program
US5745574A (en) Security infrastructure for electronic transactions
US6976165B1 (en) System and method for secure storage, transfer and retrieval of content addressable information
US20200186361A1 (en) Method and system for registering digital documents
US6199052B1 (en) Secure electronic transactions using a trusted intermediary with archive and verification request services
US7568114B1 (en) Secure transaction processor
US6678270B1 (en) Packet interception system including arrangement facilitating authentication of intercepted packets
US20010037453A1 (en) Secure electronic transactions using a trusted intermediary with non-repudiation of receipt and contents of message
US20020136410A1 (en) Method and apparatus for extinguishing ephemeral keys
US20010050990A1 (en) Method for initiating a stream-oriented encrypted communication
KR100702499B1 (ko) 메시지 무결성 보증 시스템, 방법 및 기록 매체
JP2001507528A (ja) ルート・キーが危機にさらされた時の回復
JP2007522739A (ja) 一方向性認証
CN113610526A (zh) 一种数据信任方法、装置、电子设备及存储介质
WO1999037054A1 (fr) Procede de stockage de donnees et appareil s'y rapportant
US8538893B1 (en) Apparatus and method for electronic transaction evidence archival and retrieval

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref country code: GB

Ref document number: 200014589

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 09600297

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA