WO2015188246A1 - Système infonuagique sécurisé de transfert et de mise en mémoire d'informations - Google Patents

Système infonuagique sécurisé de transfert et de mise en mémoire d'informations Download PDF

Info

Publication number
WO2015188246A1
WO2015188246A1 PCT/CA2014/050527 CA2014050527W WO2015188246A1 WO 2015188246 A1 WO2015188246 A1 WO 2015188246A1 CA 2014050527 W CA2014050527 W CA 2014050527W WO 2015188246 A1 WO2015188246 A1 WO 2015188246A1
Authority
WO
WIPO (PCT)
Prior art keywords
cloud
data center
data
context
record
Prior art date
Application number
PCT/CA2014/050527
Other languages
English (en)
Inventor
David Everett
Original Assignee
Royal Canadian Mint/Monnaie Royale Canadienne
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 Royal Canadian Mint/Monnaie Royale Canadienne filed Critical Royal Canadian Mint/Monnaie Royale Canadienne
Priority to PCT/CA2014/050527 priority Critical patent/WO2015188246A1/fr
Publication of WO2015188246A1 publication Critical patent/WO2015188246A1/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/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation

Definitions

  • the present invention relates to secure storage and transfer of information, and in particular to a cloud-based secure information storage and transfer system.
  • Cloud-based services typical ly utilize a cloud host server connected to a data network such as the Internet.
  • the cloud host server typically comprises one or more computer servers or server clusters maintained and operated by a cloud service provider.
  • a client can access the host server to utilize various cloud-based computing and storage services available on the host server.
  • a typical application of cloud-based services includes on-line cloud-hosted storage of information and records of a client.
  • the client contracts with the service provider to use the information processing and storage capacity of the host server to store the cl ient's data.
  • the costs charged by the service provider will scale w ith the amount of data being stored by the client, and the specific services being used, such as back-up/restoration and encryption.
  • Another common application of cloud-based services includes on-line cloud-hosted electronic commerce systems.
  • a merchant may use the host server to execute an e-commerce application which enables clients to browse a catalogue, select items to purchase, enter shipping and billing information, and complete payment for their purchase order.
  • the client is uti lizing both the storage capacity of the host server (e.g. for catalogues) and its computational power to properly handle multiple purchase transactions simultaneously.
  • Cloud-based services are attractive for cloud-hosted storage and e-commerce because the host servers offer very high availabi lity and scalability, with the ability to process and store enormous amounts of information. For a client primarily using storage services, this means that they can use the cloud-based services to store all of their records, and can access those records from any device connected to the network.
  • the high availability offered by the cloud server means that any or all of the company ' s members may access the data at any given time.
  • the high avai lability offered by the cloud server means that large numbers of transactions can be handled simultaneously.
  • cloud-based services suffer a l imitation in that data stored on a host server is vulnerable to un-authorized access and other forms of misuse.
  • This difficulty arises from the fact that a client must trust a legally unrelated party (in this case the service provider) to ensure the security and integrity of the client ' s data.
  • the client may use passwords or other authentication methods to try to control access to their account and/or data.
  • the authentication algorithms are executed on the host server, and the passwords and/or other authentication information will be received by the host server during a user log-on process.
  • the client must trust that the service provider wi ll not manipulate the authentication algorithms or misuse the authentication information provided by the user.
  • the user may encrypt their data to provide an additional layer of security.
  • a client may encrypt their data stored in a cloud-hosted database.
  • a merchant may use a secure payment module which uses encrypted messaging to convey a customer's financial information.
  • the encryption algorithms are executed on the host server, and the keys will be stored on the host server at least for the duration of a user session.
  • the client must trust that the service provider will not manipulate the encryption algorithms (e.g. to provide a "back-door " ) or misuse the keys stored on the server during a user session.
  • OlOj In order to address these challenges, some clients use cloud-based services for non- critical information only, and maintain their own secure servers for critical information.
  • HSMs Hardware Security Modules
  • HSMs Hardware Security Modules
  • HSMs are commercial ly available secure computer systems that are particularly well suited for implementing secure servers.
  • HSMs suffer disadvantages in that they are expensive, and have a limited storage capacity.
  • the limited storage capacity naturally limits the size of the database that they can maintain, which in turn limits the number of users that can be supported by any given HSM unit.
  • the high cost of HSMs means that increasing the number of supported users by increasing the number of HSMs tends to be very expensive. This problem is compounded by the fact that a client may need to maintain duplicate databases (and thus HSMs) to provide data redundancy and automated fail-over in the event of an HSM failure.
  • an aspect of the present invention provides an secure cloud-based data storage and transfer system.
  • the system includes a data network, a cloud host connected to the data network, and a secure data center connected to the data network.
  • the cloud host is configured to provide cloud-based data storage and computing services to clients through the data network.
  • the secure data center is configured to provide secure encryption, decryption and data processing functions.
  • a database stored on the cloud host includes data that is cryptographically protected by the secure data center.
  • a l ightweight application executing on the cloud host receives a request message including an identifier.
  • the lightweight appl ication uses the identifier to retrieve one or more records from the database, and forwards the request message and the retrieved records to the data center.
  • the lightweight application receives records from the data center, and saves the records in the database.
  • the System includes a data network, a cloud host connected to the data network, and a data center connected to the data network.
  • the cloud host is configured to provide a computing service to subscribers through the data network.
  • the data center is configured to provide secure encryption, decryption and data processing functions.
  • a context database stored on the cloud host contains context information defining a respective context of each one of a plurality of virtual stores. At least a portion of the context information is cryptographically protected by the data center.
  • a l ightweight secure transfer appl ication executes on the cloud host and is configured to respond to a request message to transfer content to or from a subscriber's virtual store by: retrieving a record representing a respective context of the subscriber from the context database; and forwarding the transfer request message and the retrieved record to the data center.
  • the secure transfer application is also configured to save records received from the data center in the context database.
  • the lightweight application emulates a conventional cloud- based service, such as an e-commerce or electronic payment application.
  • cl ients may exchange messaging with the lightweight application in a conventional manner to access and use the service being emulated by the application.
  • data associated with the service is stored in cryptographical ly protected database maintained on the cloud host, while computing operations of the service are performed in the secure data center.
  • Security of the data saved in the database is provided by the encryption algorithms and keys that are stored and used locally within the data center.
  • the data center may be managed by the owner of the data, or a service provider contracted to secure the data on behalf of the data owner.
  • An advantage of the present technique is that it combines the benefits of cloud-based services with enhanced security afforded by locally held encryption keys and algorithms.
  • FIG. 1 is a block diagrams schematically illustrating a message exchange system in accordance with a representative embodiment of the present invention
  • FIG. 2 schematically illustrates a representative context database usable in the embodiment of Fig. 1 ;
  • FlGs. 3A and 3B are message flow diagrams schematically illustrating a possible scenario for completing an e-commerce transaction in the embodiment of FIGs. 1 and 2; and
  • FlGs. 4A and 4B are flowcharts schematical ly il lustrating representative steps and process rules implemented in the HSM manager and HSMs of FIG. 1 .
  • the present invention provides methods and systems for cloud-based data storage and transfer.
  • the present technique is described by way of an example embodiment in which a cloud-based payment service is implemented.
  • the present technique is not limited to such embodiments. Rather, it will be appreciated that the present techniques may be advantageously used to implement any cloud- based service in which it is desired to securely store and/or transport information using a cloud host.
  • the present technique provides a secure system that maintains a local set of secret keys and encryption/decryption functions, which enables data to be cryptographically secured.
  • a lightweight application that executes on a cloud host server interacts with the secure system to store cryptographically secured data on the cloud host system.
  • the high availability and scalabil ity of the cloud host system is used for data storage, but the data is secured by cryptographic keys and algorithms that are locally maintained on the secure system.
  • the owner of the secure system does not need to trust security features offered by the cloud host system.
  • a representative cloud-based secure information storage and transfer system 2 in accordance with the present invention comprises a cloud host system 4 and a secure system represented by a data center 6. both of which are connected to a data network 8, such as, for example, the Internet.
  • Merchant systems 10 and individual users 12 may interface with the cloud host system 4 to access and use cloud based applications, such as e-commerce applications, for example.
  • the cloud host system 4 may be managed by a cloud service provider and may comprise one or more servers or server clusters configured to provide computing and storage services to a plurality of subscribers of the cloud service provider.
  • Cloud host systems of a type usable in the present technique are well known, and cloud hosted services are readily available from several cloud service providers (such as, for example. Amazon.com, and Google.com).
  • content providers will enter into a subscription contract with a cloud service provider, and will then use the cloud host 4 to offer cloud-based services to consumers.
  • content providers may include a merchant and a payment services provider.
  • the merchant may enter into a subscription contract with the cloud service provider, and so use the cloud host 4 to execute an e-commerce application 14 offering the merchant's products for sale.
  • the e-commerce application 14 may use a database 16 stored on the cloud host 4 and containing one or more catalogues of products that can be purchased from the merchant.
  • the payment services provider may enter into a subscription contract with the cloud service provider, and use the cloud host 4 to execute a payment application 20 for enabling monetary transactions between subscribers of the payment services provider.
  • the merchant may enter into a subscription contract with the payment services provider so that consumers may use the payment functions offered by the payment services provider to complete their purchase transactions.
  • an individual user 12 may use their communication device 1 8 to access the e-commerce application 14, which then may permit the user 12 to browse the catalogue and select items the user 1 2 wishes to purchase.
  • the e-commerce application 14 may access the payment application 20 in order to complete the purchase transaction.
  • the user 12 may, or may not be a subscriber of either the cloud host service provider or the merchant. However, it is contemplated that both the merchant and the user 12 will have to be a subscriber of the payment services provider in order to complete monetary transfers using the payment services provider ' s system.
  • the payment service provider may initialize a respective virtual store for each subscriber, which can be used in a manner analogous to a wallet to store value owned by that subscriber.
  • each virtual store is associated with a unique identifier 24, encryption keys 26, and a digital certificate 28.
  • the payment service provider may initialize a respective record associated with each virtual store in a context database 22.
  • the encryption keys 26 may comprise a public/private key pair.
  • the respective virtual store Identifier 24, keys 26 and Digital Certificate 28 assigned to each subscriber ' s virtual store can be supplied to each subscriber (in this case the merchant and the user) for use in transactions.
  • the merchant's ID 24m. keys 26m and Certificate 28m are saved on the Merchant system 1 0, while the user ' s ID 24s. keys 26s and Certificate 28s are saved on the subscriber's communication device 1 8.
  • the encryption keys and digital certificate may be issued by a trusted issuing authority, such as, for example, Verisign. However, this is not essential.
  • the payment services provider manages the data center 6, generally comprises a manager 30 connected to one or more secure servers 32.
  • the manager 30 controls the flow of messages into and out of the data center 6.
  • the manager 30 distributes messaging across the secure servers 32, for example to provide load balancing or redirection in the event of a failure of one of the secure servers 32.
  • the manager 30 may also provide encryption and decryption services, as will be described in greater detail below.
  • the manager 30 is provided as a Hardware Security Module (HSM) of a type known in the art and commercially available, and executing suitable software to implement the appropriate functionality.
  • HSMs Hardware Security Modules
  • Security of the data center 6 is enhanced by configuring the manager 30 to only exchange messages with the Payment Application 20.
  • One way of accomplishing this is to establish and maintain a secure connection 34 or Virtual Private Network (VPN) between the manager 26 and the Payment Appl ication 20 using a known tunnelling protocol, for example.
  • the manager 30 can be configured to accept and send messages through the secure connection 34, and to discard messages received via the data network 8 from any other source.
  • the security of the data center 6 may also be enhanced by ensuring that the network address of the data center 6 is known only to the Payment Application 20, and is not advertised to the network.
  • FIG. 2 il lustrates a viable format of the Context database 22, although other formats may be used, if desired.
  • the Context database 22 is formatted into records 36, each record 36 representing a respective virtual store associated with a subscriber, and containing fields for storing the respective ID 24.
  • Keys 26 and Certificate 28 uniquely assigned to the virtual store, a current content (Cur.Val) 38 and a log 40.
  • the Keys 26 and Certificate 28 facilitate cryptographic security functionality such as encryption and digital signature using, for example, well-known Public Key Infrastructure (PKI) techniques.
  • the log 40 contains information relating to each transaction executed by or on behalf of the virtual store. In some embodiments, this information may include the at least a portion of each value transfer message generated or received by the virtual store, as will be described in greater detail below.
  • each record 36 of the context database 22 may also include a field identifying a currency 42 of the current content 38. and a count 42 of transactions that have been completed by (or on behalf of) the virtual store represented by that record 36. Taken together, the contents of a record 36 provides the context of a respective virtual store assigned to a subscriber.
  • each record is preferably cryptographically protected by the data center 6 using a combination of encryption, checksums and digital signatures.
  • the ID field 24 is unencrypted, so that the payment application 20 can readily use the store ID contained in received messages (as wil l be described in greater detail below) to retrieve a record 36 (or "virtual store context " ) from the context database 22 using well known techniques.
  • the Keys 26 are encrypted using one or more secret keys maintained locally by the data center 6.
  • one or more other fields, such as the certificate 28 and the current content (Cur.Val) 38 may also be encrypted.
  • This arrangement is beneficial, in that it allows any given record 36 to be readily retrieved from the Context Database 22, and updated using known techniques; but at the same time maintains security by ensuring that it is computationally infeasible for any party other than the data center 6 to modify its contents or read its secret data.
  • FIG. 3A is a message flo diagram illustrating an example operation of the present technique for the case of an e-commerce transaction implemented in the system of FIG. 1 .
  • a user 12 uses their communications device 1 8 to access the merchant ' s e-commerce appl ication 14, browse the merchant ' s product catalog, and select an item to purchase, all in a conventional manner.
  • the e-commerce site 1 4 Based on the user' s purchase selection, the e-commerce site 1 4 initiates a payment sequence, by formulating a Value Request Message (VRM) containing the ID 24m of the merchant ' s virtual store as the intended recipient, and the payment amount owing as the content to be transferred, and sends this VRM to the user ' s communication device 1 8 (at S4).
  • VRM Value Request Message
  • the subscriber ' s communication device 1 8 redirects the VRM to the Payment Application 20 (at S6).
  • the redirected VRM may also include the ID 24s and Certificate 28s of the user ' s virtual store.
  • the Payment Application 20 may perform verification process (at S8) to confirm the subscriber' s ID 24s and Certificate 28s. In some embodiments, the Payment Application 20 may also attempt to obtain confirmation of the User ' s acceptance of the transaction. In some embodiments, the verification processes may be handled within secure connections (for example Secure Sockets Layer, SSL, connections) set up for this purpose between the Payment Application 20 and either one or both of the e-commerce appl ication 14 and the Cloud Host 4. In some embodiments, the Payment Application 20 may obtain information of the transaction (e.g. user ' s ID 24s and the transaction amount) from the e-commerce application 14.
  • secure connections for example Secure Sockets Layer, SSL, connections
  • the Payment Application 20 may obtain confirmation of the user ' s authentication status from either the cloud host 4 or the e-commerce application 14. In cases where the user 12 has already completed login and/or authentication processes with either or both of the cloud host 4 and the e-commerce application 14, it may not be necessary for the Payment Application 20 to request the user 12 to complete further authentication steps in order to complete the transaction. However, if desired, these further additional authentication steps may be performed using known techniques. [0036] Upon successful completion of the verification process, the Payment Application 20 requests (at S I O) the user's virtual store context from the context database 22. Preferably, the database record 36 representing the subscribers ' virtual store is locked (at S I 2) to prevent another process from accessing or revising that record before completion of the current transaction.
  • the record 36 may be locked by the database engine (not shown), in response to the request message from the Payment Application 20. In other embodiments, the record may be locked by the Payment Application 20 itself, for example by means of suitable control messages.
  • the Payment Application 20 Upon receipt of the subscriber's virtual store context from the VSM context database 22 (at S I 4). the Payment Application 20 forwards the VRM and the subscriber ' s context (at S I 6) to the data center 6 for processing.
  • the manager 30 may decrypt and/or validate the integrity of the user ' s context, and pass the VRM and the decrypted context to a secure server 32 for processing.
  • the manager 30 may pass the encrypted context and the VRM to a secure server 328, which will then decrypt the context prior to processing the VRM.
  • the secure server 32 processes the VRM and the decrypted context (S I 8) in accordance with a set of processing rules (described in greater detail below), to generate (S20) at least: a value transfer message (VTM) for conveying the payment amount owing to the Merchant and an updated version of the user's context.
  • VTM value transfer message
  • the secure server 32 performs encryption/decryption functions
  • at least a portion of the updated user ' s context may be encrypted and/or secured using cryptographic checksums by the secure server 32 prior to passing them to the manager 30.
  • the manager 30 may encrypt and/or generate checksums or digital signatures securing portions of the updated context prior to forwarding it to the Payment Application 20.
  • the secure server 32 may also generate one or more checksums, signatures or other validation data, which may be passed to the manager 30 and/or the Payment Appl ication 20 so that the integrity and/or un iqueness of the VTM and updated user's context can be verified.
  • the Payment Application 20 may forward the VTM to the subscriber ' s communication device 1 8 (at S22).
  • the updated context may then be stored (at S24) in the appropriate record 36 of the context database 22, and that record unlocked (at S26) to permit other transactions
  • the user's communication device 1 8 can forward the VTM to the e-commerce application 14 (at S28) in order to complete the transaction.
  • a representative process for completing a transaction following receipt of the VTM by the e-commerce appl ication 14 is described below with reference to FIG. 3B.
  • an acknowledgment message may be sent (at S30) to the user's communication device 1 8.
  • a corresponding acknowledgment message may also be sent by the e-commerce application 14 to the Merchant's system 10.
  • the e-commerce application 14 when the e-commerce application 14 receives a VTM from a user's communication device 18 (at S28), it formulates and sends a load request message (at S32) containing the VTM to the Payment Application 20.
  • the Payment Application 20 may perform a verification process (at S34) to confirm the integrity of the VTM.
  • the verification process may use the User's Certificate 28s and/or checksums contained in the VTM to verify that the VTM content has not been changed since it was generated.
  • the payment appl ication 20 may discard the VTM and the Load request message.
  • the payment application may return a failure notification message (not shown) to the e-commerce application 14.
  • the Payment Application 20 requests the Merchant ' s virtual store context from the context database 22 (at S36).
  • the context database record 36 representing the Merchant ' s virtual store is locked (at S38) to prevent another process from accessing or revising that record before completion of the current transaction.
  • the record may be locked by the database engine (not shown), in response to the request message from the Payment Application 20.
  • the record may be locked by the Payment Application 20 itself, for example by means of suitable control messages.
  • the manager 30 may decrypt and/or validate the integrity of the Merchant ' s context, and pass the VTM and the decrypted context to a secure server 32 for processing.
  • the manager 30 may pass the encrypted context and the VTM to a secure server 32, which will then decrypt the context prior to processing the VTM.
  • the secure server 32 processes (at S44) the VTM and the decrypted context in accordance with a set of processing rules (described in greater detail below), to generate at least: an acknowledgment message indicating success or failure of the transaction; and an updated version of the Merchant ' s context.
  • At S46 these items are passed back to the manager 30 for forwarding to the Payment Application 20 (at S46).
  • the secure server 32 performs encryption/decryption functions
  • at least a portion of the updated Merchant' s context may be encrypted by the secure server 32 prior to passing them to the manager 30.
  • the manager 32 may encrypt portions of the updated Merchant' s context prior to forwarding them to the Payment Application 20.
  • the secure server 32 may also generate one or more checksums, signatures or other validation data, which may be passed to the manager 30 and/or the Payment Application 20 so that the integrity of the updated subscriber's context can be verified.
  • the Payment Application 20 may store the updated Merchant's context in the appropriate record 36 of the context database 22 (at S50). and unlock that record (at S52) to permit other transactions.
  • corresponding acknowledgment messages may be sent (at S54) to any one or more of the e-commerce application 14. the user's communication device 1 8 and/or the merchant system 1 0 to indicate that the transaction has been successfully completed.
  • the Payment Application 20 may send failure messages to any one or more of the user's communication device 1 8, the merchant system 10. and the e-commerce application 14 so that the user's purchase may be cancelled or other steps taken to identify and rectify the problem.
  • the secure server 32 processes a VRM and the user ' s context in accordance with a set of processing rules at step S I 8, to generate at least a VTM, and an updated version of the user ' s virtual store context.
  • the secure server 32 processes a VTM and the Merchant's context in accordance with a set of processing rules at step S44, to generate at least an Acknowledgment message and an updated version of the Merchant's context. Representative process rules for each of these operations are described below with reference to FIGs.4A and 4B, respectively.
  • FIG. 4A is a flow chart illustrating representative processing rules for processing a VRM and a user's context to generate a VTM and an updated version of the user's context.
  • the process begins with the secure server 32 receiving the VRM and decrypted user's context.
  • the secure server 32 compares (at S62) the content (Val.) to be transferred with the current content (Cur.Val) 38 stored in the user's context. If Cur.Val 38 is less than the content to be transferred (Val.), then the secure server 32 generates and returns an error message (at S64).
  • the secure server 32 decreases the Cur.Val 38 by the content (Val.) to be transferred (at S66), and then generates (at S68) a Value Transfer Message (VTM) containing the content (Val.) to be transferred, the ID 24s of the user ' s virtual store, the ID 24m of the merchant ' s virtual store and a nonce which uniquely identifies the VTM. at least among the content transfer messages generated and sent on behalf of the user's virtual store.
  • the secure server 32 then applies a Digital Signature (DS) and the user's Certificate 28 to the VTM (at S70).
  • the secure server 32 records information about the transfer in the Log field 40 of the user ' s context (at S72). Finally, the secure server 32 returns (at S74) the digitally signed VTM and the updated context to the Manager30.
  • the VTM generated by the secure server 32 contains the ID 14s of the user's virtual store. However, this is not essential. In some embodiments, the user's virtual store I D 14s may be omitted, if desired.
  • the VTM generated by the secure server 32 contains a nonce. In general, the nonce can be any binary or alpha-numeric string that enables a recipient party to verify the uniqueness of the VTM, at least among VTMs generated by or on behalf of the user's virtual store. In some embodiments, the nonce may be generated by the secure server 32 as part of the VRM processing. However, this is not essential.
  • the nonce may be generated by the recipient party (eg the Merchant's system 1 0) prior to initiation of the transaction, and included in the VRM generated by the e-commerce application 14 (FIG. 3A, at S4).
  • This arrangement is beneficial, in that enables the Merchant to positively associate any given VTM loaded to its virtual store to a specific purchase transaction, without altering the ability of the secure server 32 to detect and handle duplicates.
  • FIG. 4B is a flow-chart showing a representative process which may be executed by the Data Center 6 to load value contained in a received VTM message to a subscriber' s (in the illustrated example, the merchant ' s) virtual store.
  • the process begins with the secure server 32 receiving the VTM and decrypted Merchant ' s context.
  • the secure server 28 uses the Certificate 28 to verify (at S80) the digital signature of the received VTM. If the verification fails, the VTM is discarded (at S82), and an error message is returned (at S84) to the Manager 30 before the process is terminated.
  • the secure server 32 uses the nonce and both the user ' s context ID 24s and the merchant's context ID 24m to compare (at S86) the received VTM with the decrypted Merchant's log field 40 to determine whether the VTM is a duplicate of a VTM previously received from the user's virtual store. If it is a duplicate, the VTM is discarded (at S82), an error message is returned to the Manager 30 (at S84) and the process is terminated. Otherwise, the secure server 32 updates the merchant ' s log 40 with a transaction record including information about the transaction (at S88), and increases the current content (Curr.Val) 36 stored in the Merchant ' s context by the content (Val.) contained in the VTM (at S90). Finally, the secure server 32 returns (at S92) an acknowledgment message and the updated Merchant' e context to the HSM manager 26, indicating that the VTM message has been successfully processed.
  • the log field 40 maintains a record of content transfers into and out of each virtual store.
  • the information recorded in the log field 40 comprises the content of each transfer message received of sent by (or on behalf of) each virtual store.
  • a digest of each transfer message may be recorded, rather than the entire message.
  • the digest may take the form of a hash computed over at least a portion of a respective transfer message. Recording a hash of received transfer messages, for example, enables effective detection of duplicate messages while minimizing the amount of memory required to store the log field 40.
  • sent and received Value Transfer Messages may be recorded in respective separate log fields. This arrangement is beneficial in that it facilitates respective different information sets to be recorded in each field.
  • the log field for sent messages may record the entire VTM sent by a given virtual store, while the log field for received messages merely records a hash of each received message.
  • the service provider may be desirable (or. for regulatory reasons, essential) that the service provider have knowledge of the actual identities of each of its subscribers. In such cases, anonymity of the parties involved in a transaction is not preserved, because either the host server 4 and/or the manager 30 is capable of tracking transactions involving each of its subscribers. However, this is not essential. For example, a service provider could accept anonymous requests for virtual storage media. However, it wi ll be seen that the entire on-line purchase transaction described above in reference to FIG. 3 proceeds entirely on the basis of the respective ID 24 and certificate 28 issued to the user and the merchant.
  • This information identifies the particular virtual stores involved in the transaction, and also provides the values of non-repudiation, non-revocabil ity, message integrity and message security, but it does not provide information of the actual identities of the involved parties. As such, unless the service provider has some other process for acquiring information identifying each of its subscribers and the and ID 24 and certificate 28 issued to the virtual store of that subscriber, the service provider would not have any means of identifying the parties to a transaction, and anonymity is preserved.
  • the present technique is described in terms of an electronic (e-commerce) transaction, in which a cloud-based application is a payment application 20, and the data center 6 processes VTM messages to transfer and load content in the form of a monetary value to and from each party ' s virtual store, so as to enable a purchase transaction.
  • a cloud-based application is a payment application 20
  • VTM messages to transfer and load content in the form of a monetary value to and from each party ' s virtual store, so as to enable a purchase transaction.
  • the present technique is not limited to such embodiments.
  • the techniques described herein can be used in any scenario in which it is desired to securely store and transfer information content (of any kind) between users of a cloud-based system.
  • a company may choose to implement an embodiment of the present technique to enable its employees and partners to store and access company information stored in a cloud based storage system.
  • the cloud- based application 20 executing on the cloud host 4 may operate to handle user (eg. employee) requests to retrieve or store files or data, and the data center 6 may be managed by the company to provide secure encryption/decryption of the information being stored in cloud-based storage.
  • the payment application 20 and data center 6 are managed by a payment services provider, which is separate from the cloud services provider and the merchant.
  • a payment services provider which is separate from the cloud services provider and the merchant.
  • any party including, for example, the merchant or the cloud services provider capable of managing the data center 6 may operate as the payment services provider.
  • the context database 22 includes a log field 40 for recording transaction information related to transfers may by or on behalf of each virtual store. However, this is not essential. If desired, the log field 40 may be saved in a transactions database that is separate from the context database 22. In this case, the methods described above with reference to figures 3-4may be modified as appropriate to ensure that the transaction log (or relevant parts thereof) can be properly processed and updated.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un système infonuagique comprenant un réseau de données, un hôte en nuage et un centre de données. Une base de données de contexte mémorise des contextes respectifs de multiples magasins virtuels. Une base de données de journal enregistre les transferts de contenu en provenance et à destination de chaque magasin virtuel. Au moins une partie des bases de données de contexte et de journal est chiffrée par le centre de données. Une application de transfert s'exécute sur l'hôte en nuage et répond à une requête de transfert visant à transférer du contenu en provenance d'un magasin virtuel comme suit : en récupérant le contexte du magasin virtuel depuis la base de données de contexte ; et en acheminant la requête de transfert et le contexte au centre de données. L'application de transfert répond également à une requête de charge visant à charger du contenu à destination d'un magasin virtuel comme suit : en récupérant le contexte du magasin virtuel, et un journal de transferts affectant le magasin virtuel depuis la base de données de journal ; et en acheminant la requête de charge, le contexte et le journal au centre de données.
PCT/CA2014/050527 2014-06-09 2014-06-09 Système infonuagique sécurisé de transfert et de mise en mémoire d'informations WO2015188246A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CA2014/050527 WO2015188246A1 (fr) 2014-06-09 2014-06-09 Système infonuagique sécurisé de transfert et de mise en mémoire d'informations

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2014/050527 WO2015188246A1 (fr) 2014-06-09 2014-06-09 Système infonuagique sécurisé de transfert et de mise en mémoire d'informations

Publications (1)

Publication Number Publication Date
WO2015188246A1 true WO2015188246A1 (fr) 2015-12-17

Family

ID=54832640

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2014/050527 WO2015188246A1 (fr) 2014-06-09 2014-06-09 Système infonuagique sécurisé de transfert et de mise en mémoire d'informations

Country Status (1)

Country Link
WO (1) WO2015188246A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9497602B2 (en) * 2015-01-30 2016-11-15 Mitake Information Corporation System and method of enterprise mobile message

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299313A1 (en) * 2009-05-19 2010-11-25 Security First Corp. Systems and methods for securing data in the cloud
US20120266231A1 (en) * 2011-04-18 2012-10-18 Bank Of America Corporation Secure Network Cloud Architecture
US20120284527A1 (en) * 2011-05-03 2012-11-08 International Business Machines Corporation Methods and systems for selective encryption and secured extent quota management for storage servers in cloud computing
US20120281708A1 (en) * 2011-05-06 2012-11-08 Abhishek Chauhan Systems and methods for cloud bridging between public and private clouds
US20130305039A1 (en) * 2011-05-14 2013-11-14 Anthony Francois Gauda Cloud file system
US20140075499A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Security infrastructure for cloud services
US20140075033A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Service association model
WO2014059860A1 (fr) * 2012-10-17 2014-04-24 北京卓微天成科技咨询有限公司 Méthode et système d'amélioration de la sécurité des données en informatique en nuage
US8862883B2 (en) * 2012-05-16 2014-10-14 Cisco Technology, Inc. System and method for secure cloud service delivery with prioritized services in a network environment

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299313A1 (en) * 2009-05-19 2010-11-25 Security First Corp. Systems and methods for securing data in the cloud
US20120266231A1 (en) * 2011-04-18 2012-10-18 Bank Of America Corporation Secure Network Cloud Architecture
US20120284527A1 (en) * 2011-05-03 2012-11-08 International Business Machines Corporation Methods and systems for selective encryption and secured extent quota management for storage servers in cloud computing
US20120281708A1 (en) * 2011-05-06 2012-11-08 Abhishek Chauhan Systems and methods for cloud bridging between public and private clouds
US20130305039A1 (en) * 2011-05-14 2013-11-14 Anthony Francois Gauda Cloud file system
US8862883B2 (en) * 2012-05-16 2014-10-14 Cisco Technology, Inc. System and method for secure cloud service delivery with prioritized services in a network environment
US20140075499A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Security infrastructure for cloud services
US20140075033A1 (en) * 2012-09-07 2014-03-13 Oracle International Corporation Service association model
WO2014059860A1 (fr) * 2012-10-17 2014-04-24 北京卓微天成科技咨询有限公司 Méthode et système d'amélioration de la sécurité des données en informatique en nuage

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9497602B2 (en) * 2015-01-30 2016-11-15 Mitake Information Corporation System and method of enterprise mobile message

Similar Documents

Publication Publication Date Title
EP3704620B1 (fr) Système et procédé de notification à base de chaîne de blocs
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
US11533164B2 (en) System and method for blockchain-based cross-entity authentication
US11316697B2 (en) System and method for issuing verifiable claims
US11277268B2 (en) System and method for verifying verifiable claims
EP3721603B1 (fr) Système et procédé de création d'identifiants décentralisés
US20150358296A1 (en) Cloud-based secure information storage and transfer system
WO2019144948A1 (fr) Plateforme d'authentification biométrique décentralisée
CN114616563A (zh) 用于加密密钥生成的安全环境
WO2015188246A1 (fr) Système infonuagique sécurisé de transfert et de mise en mémoire d'informations
US20150356295A1 (en) Keep-alive system and method for cloud-based database systems
WO2015188247A1 (fr) Système et procédé d'entretien pour systèmes de base de données en nuage
CN116250209A (zh) 分布式计算系统中的数据管理和加密

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14894539

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14894539

Country of ref document: EP

Kind code of ref document: A1