4.6 Carbon Chain 5G+ Cloud Storage
Carbon Chain 5G storage provides a special storage mechanism, which can not only prevent the storage of duplicate data, but also ensure the same security, break the "common sense" of the industry, and achieve both fish and bear. When using this mechanism, in addition to the user permission table, a global metadata table should be maintained to record the corresponding relationship between plaintext hash and ciphertext hash. When writing data, you should first query whether there is the same hash data, and if there is no such item, save it again
l Hash (data) → hdata to calculate plaintext hash
l If checkdup (hdata) = true goto 11, if the same data already exists, go to step 11
l The symmetric key is randomly generated by randomsym () → STK as the file storage key
l Enc (STK, data) → encdata encrypt files with storage key
l Hash (encdata) → henc to calculate ciphertext hash
l The symmetric key is generated from the plaintext of the data by genkey (data) → sData
l After adding salt, hash value is calculated. The reason for adding salt is that plaintext hash is a public value. If 5g storage blockchain is not added salt to enable partial storage, people who do not have plaintext data can also obtain the key. In order to ensure consistency, the salt value can be a fixed value.
l Enc (hdata, STK) → encstk'encrypts the storage with the symmetric key generated by the data plaintext
l Store the key. This is a very "weird" step. It uses plaintext as the key and the key as plaintext to encrypt. When most people look at this algorithm, they think it is reversed. In fact, it is specially designed in this way, and this step is the core step of de duplication after encryption.
l Putipfs (encdata) stores encrypted data into IPFs
l Putmeta (hdata, henv, encstk) stores encrypted ciphertext hash and plaintext
l The key is recorded in the global metadata table and in the plaintext hash key
l Goto 14
l Get meta (hdata) → henv, encstk'get ciphertext from global metadata table
l Storage key after hash and plaintext encryption
l Genkey (data) → sData uses the same algorithm to generate symmetric key from data plaintext
l The symmetric key is used by Dec (sData, encstk ') → STK to decrypt the storage key
l Enc (spub, STK) → encstk uses the user's encryption public key to encrypt and store the key
l Putpri (hdata, encstk) stores the encrypted storage key of the encrypted public key to the user
l The user permission list is recorded under the clear text hash item
l When getting data, take out the corresponding ciphertext hash from the plaintext hash in the global metadata table, take out the ciphertext hash from the IPFs through the ciphertext hash, take out the encrypted storage key from the permission list, decrypt the encrypted storage key with the user's encryption private key to obtain the storage key, and decrypt the encrypted data with the storage key to obtain the data plaintext.
l It is obtained by getmeta (hdata) → henc from the global metadata table through plaintext hash
l The ciphertext hash getpri (hdata) → encstk obtains the encrypted public key from the permission list through plaintext hash
l Get IPFs (henc) → encdata extract ciphertext from IPFs with ciphertext hash
l Dec (sprv, encstk) → STK encrypts the user's public key with the user's private key
l The encrypted storage key is decrypted to obtain the storage key
l Dec (STK, encdata) → data decryption to obtain file data
l The optimized DSN scheme not only effectively guarantees the security of data, but also realizes encryption and de duplication. In order to achieve better de duplication effect, the data can be divided into blocks according to a fixed length, and each block is de duplicated separately. The above scheme can only be used to store static data. When storing dynamic data, not only the ID that does not change with the content should be used to replace hash as the identification of data, but also the verification of write permission should be added to prevent the data from being covered and tampered by others.
l The creation process is as follows:
l Xun randomasm () → swpub, SwPrv randomly generates asymmetric key as write permission key
l Create (swpub) → ID creates a dynamic data, obtains a unique ID, and records the public key of the write permission corresponding to the ID
l Random sym () → STK randomly generates symmetric key as storage key
l Enc (spub, STK) → encstk uses the user's encryption public key to encrypt and store the key
l Putpri (ID, encstk) stores the encrypted storage key of the encrypted public key into the user permission list, and records it under the ID. the process of each data writing is as follows:
l Get pri (ID) → encstk to retrieve the encrypted storage key from the user permission table
l Dec (sprv, encstk) → STK encrypts the user's public key with the user's private key
l The storage key is obtained by decryption
l Enc (STK, data) → encdata encrypt files with storage key
l Hash (encdata) → henc to calculate ciphertext hash
l Enc (SwPrv, henc) → enchenc uses the public key of the ID's write permission to hash the ciphertext
l autograph
l Putdyn (ID, encdata, enchenc) writes encrypted dynamic data to sign data
l Write authorization on behalf of. When a node storing dynamic data fragments writes dynamic data, it needs to verify the write permission first
l Get key (ID) → swpub get the public key of write permission corresponding to the ID
l Hash (encdata) → henc to calculate ciphertext hash
l If Dec (swpub, enchenc) = henc write (encdata)
l The reading process of writing dynamic data is as follows:
l From the permission list, getpri (ID) → encstk obtains the data encrypted with the encryption public key corresponding to the ID
l Storage key
l Get dyn (ID) → encdata read ciphertext from dynamic data storage area with ID
l Dec (sprv, encstk) → STK encrypts the user's encrypted public key with the user's encrypted private key
l The encrypted storage key is decrypted to obtain the storage key
l Dec (STK, encdata) → data decryption to obtain file data
Last modified 6mo ago