WO2024094290A1

WO2024094290A1 - Apparatus and method for storage protection

Info

Publication number: WO2024094290A1
Application number: PCT/EP2022/080427
Authority: WO
Inventors: Arto NIEMI; Jasper SURMONT; Jan-Erik Ekberg
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-11-01
Filing date: 2022-11-01
Publication date: 2024-05-10

Abstract

A computing apparatus protects and de-protect data blocks out of and into secure isolated storage. Protecting blocks includes generating a first tag based on an incompressible block, where the tag includes integrity protection metadata, and encrypting the incompressible block to produce a first cyphertext; compressing a compressible block to produce a compressed block and a free-space, where a size of the free-space is not less than a size of a header; generating a second tag based on the compressed block, and including the first tag, the second tag, and a compression information in the header; combining the header with the compressed block, and encrypting the compressed block along with the header to produce a second cyphertext, thereby avoiding expansion of the protected blocks. De-protection uses the header information to verify integrity of the de-protected blocks.

Description

APPARATUS AND METHOD FOR STORAGE PROTECTION

TECHNICAL FIELD

The aspects of the disclosed embodiments relate generally to computer security, and more particularly to data storage protection.

BACKGROUND

Modern computing systems employ two basic types of storage, non-volatile storage or memory and volatile storage or memory. Non-volatile storage retains its contents across power cycles, and volatile storage loses its contents on power-off or reboot.

Both types of storage, also referred to as memory, require strong security to protect sensitive data. Isolation may be employed to protect storage, typically volatile memory, via hardwarebased physical access control mechanisms. Data leaving an isolated domain, such as data transferred to removable storage, must be protected cryptographically to preserve confidentiality and integrity.

Confidentiality may be protected by encrypting data leaving a secure environment. Integrity may be protected by generating cryptographically secure integrity protection metadata (IPM), also referred to as a message authentication code (MAC), or a tag. The typical size of a tag that covers the plaintext or cyphertext of a single encryption operation is between 16 (as in AES- GCM) and 64 bytes (as in HMAC-SHA-512). IPM may be much larger when replay protection is also required.

Migration, which is the process of moving a running program from one device to another, requires both program code and data to be migrated. Migration requires the security guarantees be upheld during transmission, as well as at the source and destination. Migration of integrity protected data also requires the IPM to be migrated along with the protected data.

Thus, there is a need for improved apparatus and methods capable of cryptographically preserving confidentiality and integrity of data leaving an isolated domain that are efficient and do not cause any data expansion. Accordingly, it would be desirable to provide methods and apparatus that address at least some of the problems described above. SUMMARY

The aspects of the disclosed embodiments are directed to apparatus and methods configured to protect and de-protect blocks based on protection and de-protection techniques adapted to protect data in situ without any data expansion. Compression is employed to avoid data expansion, and the protection and de-protection are configured to avoid data expansion when incompressible blocks are encountered. The disclosed embodiments provide improved efficiency and may be fully implemented in software thereby providing portability and transparency.

According to a first aspect, the above and further implementations and advantages are obtained by an apparatus that includes a processor and a memory. The processor is configured to protect an incompressible block and a compressible block. Protecting the incompressible block includes generating a first tag based on the incompressible block and encrypting the incompressible block to produce a first cyphertext. Protecting the compressible block includes compressing the compressible block to produce a compressed block and a free-space, where a size of the free-space is not less than a size of a header. Generating a second tag based on the compressed block and generating the header, where the header includes the first tag, and the second tag. Combining the header with the compressed block and encrypting the compressed block along with the header to produce a second cyphertext. Storing the first and second tag in the free-space created by compressing the compressible block avoids expansion of the data.

In a possible implementation form, the processor is configured to generate compression information. The compression information is included in the header and includes compression parameters and an indication of a compression algorithm used to compress the compressible block. Including compression information in the header allows different compression algorithms to be used for each compressible block.

In a possible implementation form, the incompressible block comprises a plurality of incompressible blocks and the first tag is generated based on the plurality of incompressible blocks. Configuring the first tag to include IPM for multiple incompressible blocks allows protection of data that includes multiple sequential incompressible blocks. In a possible implementation form the processor is configured to select a compression algorithm from a prioritized list of compression algorithms. The compression algorithm is selected to provide the least costly compression method that yields a free-space that is not less than the size of the header. Improved efficiency is achieved by employing the least costly compression algorithm that provides sufficient free-space for storing the header.

In a possible implementation form, the prioritized list of compression algorithms comprises one or more of a O-replacement algorithm, a run-length encoding algorithm, a move-to-front algorithm, an interpolative coding algorithm, and an ExpGolomb algorithm. Including a range of compression algorithms in the prioritized list improves the opportunity to achieve performance improvements.

In a possible implementation form, the processor is further configured to de-protect the first cyphertext and the second cyphertext. De-protecting the first cyphertext includes decrypting the first cyphertext to recover the incompressible block and generating a third tag based on the recovered incompressible block. De-protecting the second cyphertext includes decrypting the second cyphertext to recover the compressed block and the header, generating a fourth tag based on the recovered compressed block, verifying an integrity of the recovered incompressible block by comparing the third tag with the first tag, and verifying an integrity of the recovered compressed block by comparing the fourth tag with the second tag. When the integrity of the recovered incompressible block and the integrity of the recovered compressible block are successfully verified, de-protecting proceeds by decompressing the recovered compressed block based on the compression information to produce the compressible block. The deprotection process verifies integrity based only on the protected blocks, without any additional data.

In a possible implementation form, the recovered incompressible block comprises a plurality of recovered incompressible blocks, and the processor is configured to generate the third tag based on the plurality of incompressible blocks. Incorporating IPM for the plurality of incompressible blocks into the third tag allows the integrity of multiple sequential incompressible blocks to be ensured.

In a possible implementation form, the processor includes a cache memory, and the processor is configured to store a message authentication code state in the cache memory while generating the third tag. Storing the message authentication code state in the cache memory improves processing efficiency when generating the third tag.

In a possible implementation form, the apparatus further comprises a secure storage and an insecure storage, and the processor is configured to read and write the incompressible block and the compressible block from and to the secure storage and to write and read the first cyphertext and the second cyphertext to and from the insecure storage. The advantages provided by the disclosed protection and de-protection methods are particularly beneficial when moving blocks between secure and insecure storage.

In a possible implementation form, the incompressible block and the compressible block comprise a block size corresponding to a storage unit size of one or more of the secure storage and the insecure storage. Blocks conforming to a storage-unit size of the storage being used allow the protection and de-protection methods to be implemented at lower levels of the software hierarchy, thereby providing transparency to applications executing at higher levels of the software hierarchy.

In a possible implementation form, the compression information comprises a magic number, and the processor is configured to differentiate a compressed block from an incompressible block based at least in part on the magic number. Use of a magic number improves efficiency by simplifying identification of compressible blocks.

In a possible implementation form, the secure memory is isolated within a secure enclave, and the processor is configured to protect the incompressible block and the compressible block when moving the incompressible block and the compressible block outside a boundary of the secure enclave. The efficiency and transparency achieved by the protection and de-protection methods is particularly advantageous when migrating data and programs isolated within a secure enclave.

According to a second aspect, the above and further implementations and advantages are obtained by a method for protecting an incompressible block and a compressible block. Protecting the incompressible block includes identifying the incompressible block; generating a first tag based on the incompressible block and encrypting the incompressible block to produce a first cyphertext. Protecting the compressible block includes compressing the compressible block to produce a compressed block and a free-space, where a size of the firee- space is not less than a size of a header. Generating a second tag based on the compressed block and generating the header. The header comprises the first tag, and the second tag. The header is added to the compressed block the compressed block is encrypted along with the header to produce a second cyphertext. Use of compression avoids data expansion by providing space within a protected block to store both the compressed block and the header.

In a possible implementation form the method includes generating a compression information, where the compression information includes compression parameters and an indication of a compression algorithm used to compress the compressible block. The header further includes the compression information. Including compression information in the header allows the compression algorithm to be selected during protection of each compressible block.

In a possible implementation form of the method the incompressible block comprises a plurality of incompressible blocks and generating the first tag comprises generating the first tag based on the plurality of incompressible blocks. Incorporating IPM for the plurality of blocks allows integrity of multiple incompressible blocs to be verified without expanding the size of the header.

According to a third aspect, the above and further implementations and advantages are obtained by a method for de-protecting an incompressible block and a compressible block. Decompressing the incompressible block includes decrypting the first cyphertext to recover a first plaintext; identifying the first plaintext as a recovered incompressible block; and generating a third tag based on the recovered incompressible block. De-protecting the compressible block includes decrypting the second cyphertext to recover a second plain text; identifying the second plain text as a recovered compressed block and a header, where the header comprises a compression information, a first tag corresponding to the incompressible block, and a second tag corresponding to the compressed block; generating a fourth tag based on the recovered compressed block; verifying an integrity of the recovered incompressible block by comparing the third tag with the first tag; and verifying an integrity of the recovered compressed block by comparing the fourth tag with the second tag. When integrity of the recovered incompressible block and the recovered compressed block are successfully verified, the method for deprotecting decompresses the recovered compressed block based on the compression information to produce a recovered compressible block. The de-protecting method allows both incompressible and compressible blocks to be de-protected based only on the cyphertexts without any additional data.

In a possible implementation form the recovered incompressible block includes a plurality of recovered incompressible blocks and generating the third tag includes generating the third tag based on the plurality of recovered incompressible blocks. Generating an integrity protection tag based on the plurality of incompressible blocks allows integrity of the plurality of incompressible blocks to be verified without any additional data.

These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which like references indicate like elements and:

Figure 1 illustrates a block diagram of an exemplary apparatus configured to protect and deprotect blocks in accordance with aspects of the disclosed embodiments;

Figure 2 illustrates a pictorial diagram depicting an exemplary process for protecting blocks in accordance with aspects of the disclosed embodiments;

Figure 3 illustrates a pictorial diagram depicting an exemplary process for de-protecting blocks in accordance with aspects of the disclosed embodiments;

Figure 4 illustrates a flow chart of an exemplary method for protecting blocks in accordance with aspects of the disclosed embodiments;

Figure 5 illustrates a flow chart of an exemplary method for de-protecting cyphertexts incorporating aspects of the disclosed embodiments. DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

Figure 1 illustrates a block diagram of an exemplary apparatus 100 configured to protect and de-protect blocks incorporating aspects of the disclosed embodiments. The exemplary apparatus 100 of the disclosed embodiments is directed to a computing apparatus 100 configured to protect both integrity and confidentiality of data without any data expansion. Among other benefits, the disclosed embodiments provide cryptographic protection of blocks using an approach that is efficient, transparent, and that can be fully implemented in software. These improvements and advantages are obtained in part by employing lossless compression to create space for meta data required during de-protection.

Referring to Figure 1, in one embodiment the apparatus 100 comprises a processor 102 and a memory 104. The processor 102 is configured to protect an incompressible block and a compressible block. Protecting the incompressible block and the compressible block includes generating a first tag based on the incompressible block; encrypting the incompressible block to produce a first cyphertext; and compressing the compressible block to produce a compressed block and a free-space. A size of the free-space is not less than a size of a header. A second tag is generated based on the compressed block. The header is generated and combined with the compressed block. The header includes the first tag and the second tag. The compressed block is encrypted along with the header to produce a second cyphertext.

In the illustrated embodiment the processor 102 is communicatively coupled to the program memory 104. The program memory 104 stores program instructions that when executed by the processor 102 cause the processor 102 to protect and de-protect blocks of data. Also included are a secure storage 106 configured to protect the integrity and confidentiality of data stored therein, and an insecure storage 108 configured as a non-volatile storage for storing relatively large amounts of data.

The term "storage" as used herein to refers to both non-volatile storage or memory that retains its contents across device power cycles, and volatile storage or memory that loses its contents when power is removed. Examples of non-volatile storage include computer disks, solid state drives, memory sticks, and thumb drives. Examples of volatile storage include dynamic random-access memory (DRAM), central processing unit (CPU) registers, and cache memory. The secure memory 106 is configured to protect the confidentiality and integrity of information stored therein. Confidentiality will be recognized as the security property that prevents unauthorized access of data, and integrity will be recognized as the security policy that prevents unauthorized modification of data. In certain embodiments confidentiality and integrity may be protected through isolation such as by protecting volatile memory via hardware based physical access control mechanisms. Examples of appropriate access control mechanisms include processor privilege levels, hardware page tables, and world-based isolation. Isolation prevents code running outside a protected domain from accessing or modifying storage belonging to the protected domain. Isolation is commonly used to provide run-time protection for memory associated with secure enclaves and allows access only by code running within the enclave.

As used herein the term "block" refers to a unit of storage having a fixed size corresponding to the type of storage being protected. Data is read from storage and written to storage a whole block at a time. A block depends on the type of storage and may be referred to using various terms such as a disk block, memory page, or cache line. Protecting storage on a block level provides distinct advantageous over other approaches such as file level protection. These advantages include performance improvements and implementation benefits. For example, block level protection can be implemented at lower levels within the software hierarchy, such as a device driver, allowing block level protection to be fully transparent to the user of the storage. Files typically include many blocks, making it costly to validate the integrity of a file.

Optionally, the program memory 104 may be incorporated into either or both of the secure storage 106 and insecure storage 108. For example, pages or blocks of program data may be moved into secure storage for execution and transferred to insecure storage to make room in the secure storage for other pages of program memory.

Any suitable processing device or specialized processing device may be advantageously employed as the processor 102 in the exemplary apparatus 100. Examples of appropriate processing devices include, but are not limited to, a high-performance multi-core computer processing device such as those used in large cloud computing data centers, a multi-core or single core microprocessor such as those used in workstations and laptop computers, a processing device embedded in a system such as a system on a chip (SoC), or any general purpose or specialized processing device such as those used in mobile communications devices, telecommunications equipment, and smart devices configured to participate in the internet of things (loT).

The processor 102 includes various components that support and facilitate protection and deprotection of blocks. In one embodiment, either alone or in combinations with other embodiments herein, included in the processor 102 is a compression component 112 configured to perform lossless data compression and decompression on blocks. As will be discussed further below, compression is used to avoid data expansion created when protecting a block by freeing up room within each block for header information required when de-protecting the protected block. The compression component 112 may, when desired, include multiple lossless compression algorithms and an ability to select an appropriate compression algorithm based on cost and an amount of size reduction. Any suitable lossless compression algorithm may be advantageously employed, such as a 0-replacement algorithm, a run-length encoding algorithm, a move-to-front algorithm, an interpolative coding algorithm, and an ExpGolomb algorithm.

In certain embodiments, the processor 102 is configured to execute an operating system, such as the Linux operating system, that provides a block-level interface to storage 106, 108. Ablock- level interface allows the disclosed protection and de-protection methods to be implemented as a device-mapper in the operating system. A device-mapper provides the ability to transparently protect and de-protect blocks as they are transferred between insecure storage 106 and secure storage 108.

A cryptography component 116 configured to encrypt and decrypt data is included in the processor 102 to cryptographically protect data. The cryptography component 116 is configured to use an appropriate cryptographic scheme to encrypt data and generate a corresponding cyphertext, and to decrypt cyphertext data to recover the original data. As used herein "encrypted data" is referred to as cyphertext. The cryptographic scheme guarantees that only an entity in possession of the cryptographic key can read or modify the cryptographically protected data. Any suitably secure symmetric or asymmetric cryptographic scheme may be advantageously employed in the cryptography component 116 to protect confidentiality of the data.

An integrity protection component 114 is configured to generate and validate integrity protection metadata (IPM). IPM is a cryptographically secure value configured to ensure integrity of a block. A change in the block results in a change in IPM generated from the block. IPM is sometimes referred to as a message authentication code (MAC) or as a tag. As used herein the term "tag" refers to integrity protection metadata configured to ensure integrity of one or more blocks of data. Conventional tag generation methods produce IPM with sizes between about sixteen bytes, in the case of Advanced Encryption Standard - Galois counter mode (AES-GCM), to about sixty-four bytes in the case of HMAC-SHA-512 (hash based message authentication code - secure hash algorithm - 512 bit).

In one embodiment, the compression component 112, encryption component 114, and integrity protection component 118 are implemented fully in software. A software implementation allows the protect! on/de-protection processes to be easily incorporated into a wide variety of computing apparatuses. Optionally, one or more of the processor components 114, 116, 118 may be implemented or accelerated by including specialized hardware support within the apparatus. Specialized hardware implementations or support may be beneficial when additional speed or efficiency are desired.

It is important to protect data when it is moved from secure storage 106 to insecure storage 108. Confidentiality may be protected by encrypting each block and writing the resulting encrypted block to insecure storage 108. Integrity protection requires generation of a tag, sometimes referred to as IPM or an integrity protection tag, corresponding to the block being protected. Storing the tag along with the encrypted block in insecure storage would expand the size of the protected data.

Data expansion can be avoided by compressing the block using a lossless compression technique. The resulting compressed block is often smaller than the original block, thereby allowing the compressed block to be stored into a block of insecure storage with space left over. The leftover space is referred to herein as free-space and has a size equal to the difference between the block size and the size of the compressed block. Additional information, such as a tag or other information useful when de-protecting the protected block, can then be stored in the free-space without causing data expansion. The additional information to be stored in the free-space is referred to herein as a header.

The amount of compression achieved by data compression algorithms varies depending on the data being compressed. Certain blocks, when compressed, do not yield sufficient free-space to store the header. A block that when compressed yields insufficient free-space to store the header is referred to herein as an incompressible block.

The exemplary apparatus 100 avoids data expansion while protecting incompressible blocks by generating an integrity protection tag for the incompressible block and incorporating the tag as additional information when protecting a following compressible block. Consider protecting a pair of blocks formed by an incompressible block followed by a compressible block. Generating a tag for integrity protection of the incompressible block in additional data that needs to be stored along with the incompressible block. This leads to data expansion because the tag cannot be stored in the same block as the incompressible block.

In the current example the incompressible block is followed by a compressible block and the processor 102 is configured to generate a first tag for integrity protection of the incompressible block. The first tag is then included in the header stored in the following compressible block along with the compressed block. The first tag is an integrity protection tag configured to provide integrity protection for the incompressible block and may be generated within the processor 102 by the integrity protection module 114. Confidentiality protection is then provided by encrypting the incompressible block to produce a first cyphertext. The processor 102 may employ the cryptography module 116 to support generation of the cyphertext and when desired to support generation of the IPM that forms the first tag.

The processor 102 compresses the compressible block to produce a compressed block and a free-space. In certain embodiments the compression module 112 may be employed to provide compression services when compressing the compressible block. Importantly, the size of the free-space is not less than the size of the header. As used herein the term header refers to the additional information stored in the free-space. The header may include any desired information such as information necessary to facilitate de-protection of one or more blocks, or other information related to the protection and de-protection of blocks. For example, a header may include one or more integrity protections tags and compression information such as an indication of a compression algorithm and compression parameters necessary to decompress a compressed block.

A second tag is generated by the processor 102 based on the compressed block. The second tag may include IPM configured to provide integrity protection for the compressible block. A header is generated by the processor 102, where the header includes the first tag and the second tag. The header is combined with the compressed block and encrypted to form a second cyphertext. The first cyphertext and second cyphertext provide both confidentiality and integrity protection for the incompressible and compressible blocks without data expansion, i.e., the first cyphertext, and second cyphertext can be stored using only two blocks of insecure storage.

As an aid to understanding, an exemplary protection process 200 is presented in Figure 2. The exemplary process 200 is suitable for protecting blocks of data in a computing apparatus, such as the exemplary apparatus 100 described above and with respect to Figure 1. The exemplary process 200 solves the problem of data expansion by using lossless compression to compress blocks to create sufficient free-space to store integrity protection metadata along with the compressed block within the same space as the original compressible block.

Figure 2 depicts a plurality of unprotected blocks Po, ... P3 along the top row 238, with the corresponding plurality of protected blocks Co, ... C3, also referred to herein as cyphertexts or cyphertext blocks, depicted along the bottom row 242. As will be discussed in more detail below, steps 240 performed to protect each block Po, ... P3 are shown between the top and bottom rows, with arrows indicating data flows and processing steps associated with the exemplary protection process 200.

Figure 2 shows two compressible blocks Po, P3 and two incompressible blocks Pi, P2. For efficiency and ease of implementation, the size of each unprotected block Po, ... P3 corresponds to a block size of the storage medium or sub-system being used.

The first unprotected block Po in the illustrated embodiment is a compressible block. Protection of the first compressible block Po begins by employing a lossless compression algorithm to compress 202 the block Po. Compressing 202 the block Po frees space within the block allowing a header to be stored within the block Po without expanding the size of protected data. Compressing 202 the block Po produces a compressed block Xo and a free-space Fo. The size of the free-space Fo is the difference between the size of the block Po and the size of the compressed block Xo. A block is defined herein as compressible when the size of free-space produced by compressing the block is sufficiently large to hold the header, i.e., the free-space is not less than the size of the header. This allows both the compressed block Xo and the header Ho to be stored within a single block. Block 230 illustrates a block where the compressed block Xo and the header Ho are both stored within the space of a single block.

IPM 204 is generated to protect integrity of the compressed block. The IPM is incorporated into the header as local IPM or a local tag along with compression information and combined with the compressed block Xo as illustrated by the combined block 230. Confidentiality is protected by encrypting 208 the combined compressed block and header 230 to produce a cyphertext Co, which may also be referred to as a protected block Co.

The second unprotected block Pi and third unprotected blocks P2 illustrated in Figure 2 are incompressible blocks, which means the free-space produced by compression is smaller than the header size. Adding a header to an incompressible block would result in data expansion. Therefore, integrity protection of incompressible blocks requires a different approach than is used when protecting compressible blocks.

Integrity protection for the first incompressible block Pi is provided by generating 210 IPM based on the unprotected block Pi. The incompressible block Pi is then encrypted 212 to produce a cyphertext CL

Storing both the generated 210 IPM along with the cyphertext Ci would expand the amount of data being stored. To avoid data expansion, the generated 210 IPM is carried forward 244 and incorporated during protection of the following block P2. In the example illustrated in Figure 2, the first incompressible block Pi is followed by another incompressible block P2. When an incompressible block, such as incompressible block Pi, is followed by another incompressible block such as block P2, the IPM carried forward 244 from the prior incompressible block Pi is updated based on the second incompressible block P2 to produce a multi-block IPM (MIPM) that ensures integrity of both incompressible blocks Pi and P2. Confidentiality of the second incompressible block P2 is provided by encrypting 216 block P2 to produce a cyphertext C2.

The last block P3 illustrated in Figure 2 is a compressible block which is compressed 218 to produce a compressed block X3 and a free-space F3, where the free-space F3 is sufficiently large to hold the header H3. Local IPM 220, also referred to as a local tag, is generated based on the compressed block X3 and incorporated into the header H3. The MIPM 214 that was generated while protecting the preceding incompressible block P2 is passed forward 246 where it may be finalized 222 and incorporated into the header H3. The header H3 is then combined 226 with the compressed block X3 and encrypted 228 to produce a protected cyphertext C3.

A more detailed view of the header H3 is shown in an expanded view of a header 230. The header 230 includes a local IPM 234 configured to protect integrity of the compresses block, such as compressed block X3, and an MIPM 236 configured to protect the integrity of one or more preceding incompressible blocks, such as incompressible blocks Pi and P2. In certain embodiments it may be desirable to include compression information 232 in the header 230. The compression information 230 may include an indication of the compression algorithm used when compressing the block as well as any desired compression parameters useful when decompressing the block.

In the above example 200, two incompressible blocks Pi, P2 precede the compressible block P3, and MIPM 222 corresponding to the two blocks Pi, P2 is incorporated into the header H3. Those skilled in the art will readily recognize that MIPM information corresponding to any number of one or more incompressible blocks may be advantageously incorporated into the header H3 as desired.

Figure 3 illustrates a pictorial diagram depicting an exemplary process 300 for de-protecting blocks incorporating aspects of the disclosed embodiments. The exemplary process 300 is appropriate for use in a computing apparatus, such as the exemplary apparatus 100, when deprotecting a plurality of cyphertexts Co, Ci, ... C3, such as the cyphertexts produced by the exemplary protection process 200 described above and with reference to Figure 2.

Figure 3 employs the same illustrative constructs as used in Figure 2 where a plurality of cyphertext blocks Co, ... C3 is depicted along the bottom row 350 with the corresponding plurality of unprotected blocks Po, ... P3 depicted along the top row 354. Steps performed while de-protecting the plurality of cyphertexts Co, ... C3 are shown in the area 352 between the top row 354 and bottom row 350, with arrows indicating data flows and operations performed during de-protection.

De-protection of the plurality of cyphertexts Co, ... C3 begins by de-protecting the first cyphertext Co, to produce a corresponding unprotected compressible block Po. The first cyphertext Co is decrypted 310 to produce plaintext 308 which includes the recovered compressed block X’o and a header Ho. A new tag 306 is generated based on the recovered compressed block X’o. Integrity of the recovered compressed block X’o is verified by comparing 344 the new tag 306 with the local tag 304 extracted 346 from the header Ho. When the new tag 306 matches the local tag 304, integrity of the recovered compressed block X’o is verified and the recovered compressed block X’o is decompressed 302 to produce the original unprotected compressible block Po. In certain embodiments, compression information 312 is included in the header Ho, and used to support decompression 302.

The following two cyphertexts Ci, C2 correspond to incompressible blocks Pi, P2. De-protecting the first incompressible block is achieved by decrypting 316 the cyphertext Ci to recover the unprotected incompressible block Pi and generating an external tag 314 including IPM configured to indicate integrity of the recovered unprotected block Pi. Incompressible blocks do not include a header so no IPM is available at this point to verify integrity of the recovered incompressible block Pi. The external tag 314 is fed forward 340 for use during processing of the next cyphertext C2.

Cyphertext C2 is decrypted to recover an incompressible block P2. The external tag 314 that was fed forward 340 from the prior block is updated 318 to include IPM corresponding to the recovered incompressible block P2 and incorporated into a multiblock tag 318 configured to verify integrity of both recovered incompressible blocks Pi and P2. The updated multiblock tag 318 is again fed forward for use during processing of the next cyphertext C3.

The cyphertext block C3 corresponds to a compressible block P3 and is decrypted 338 to produce a recovered compressed block X’3 and a header H3. A new tag 330 is generated 348 based on the recovered compressed block X’3 and is compared 332 to a local tag 328 extracted from the header H3. When the tags match integrity is verified and the recovered compressed block X’3 can be decompressed to produce the original unprotected block P3.

Referring once again to the exemplary apparatus 100 illustrated in Figure 1, the processor 102 may optionally be configured to generate compression information describing the compression processing used when generating the compressed block. The compression information may include any information useful when decompressing the compressed block, such as compression parameters, an indication of a compression algorithm used to compress the compressible block, or other appropriate compression information as desired. The compression information may be incorporated into the header where it will be available during de-protection of the block.

De-protecting a cyphertext to recover the original block requires knowledge of the decryption key and knowledge of the compression algorithm and associated compression parameters to properly decompress the compressed block. When desired, the compression algorithm and parameters can be determined a priory and exchanged in advance. However, the efficiency and size reduction of compression algorithms is data dependent, and can vary greatly from one block to another. Significant efficiencies and other advantages may be obtained by selecting the compression algorithm and parameters for each block when the block is being compressed.

Compression algorithms offer a trade-off between amount of size reduction provided and the computational costs associated with the compression. In the above-described embodiments, generation of free-space in excess of that required to store the header is unnecessary and can waste processing resources. In one embodiment, the processor 102 is configured to select a compression algorithm from a prioritized list of compression algorithms. The list is prioritized according to cost and resulting amount of compression. Cost as used herein refers to the amount of processing resources consumed during compression such as processing time, memory usage, power consumption, or other limited processor resources. By selecting the least costly algorithm that also provides sufficient free-space, significant savings can be achieved.

In the exemplary apparatus 100 the processor 102 may be further configured to de-protect a first cyphertext and a second cyphertext, such as the first and second cyphertexts produced by the protection process described above. As above, the first cyphertext corresponds to a protected incompressible block and the second cyphertext corresponds to a protected compressible block. De-protecting the first cyphertext and the second cyphertext includes decrypting the first cyphertext to recover the incompressible block. In certain embodiments, the processor 102 may employ a cryptography module 116 to support decrypting the first cyphertext to recover the incompressible block. Decryption may be performed by a software process without hardware support. The processor 102 generates a third tag based on the recovered incompressible block. The third tag is configured to support integrity validation and includes IPM corresponding to the recovered incompressible block.

The second cyphertext is decrypted by the processor 102 to recover the compressed block and the header. The header includes information necessary to de-protect the first cyphertext and the second cyphertext. In one embodiment the header includes a first tag corresponding to the compressible block, and a second tag corresponding to the incompressible block. Optionally, the header may further include compression information to aid decompression of the compressed block.

The processor 102 generates a fourth tag based on the recovered compressed block. The fourth tag provides IPM configured to ensure integrity of recovered compressed block.

The processor 102 verifies an integrity of the recovered incompressible block by comparing the third tag with the first tag and verifies an integrity of the recovered compressed block by comparing the fourth tag with the second tag. When the third tag matches the first tag, integrity of the recovered incompressible block is verified indicating the recovered incompressible block is the same as the originally protected incompressible block. When the second tag matches the fourth tag, integrity of the recovered compressed block is verified indicating the recovered compressed block is the same as the originally protected compressed block.

When integrity of the recovered incompressible block and integrity of the recovered compressible block are successfully verified, the processor 102 decompresses the recovered compressed block to produce a verified copy of the original compressible block.

As discussed above, the compressible block may be preceded by any number of one or more incompressible blocks and the first and third tags are generated based on the one or more incompressible blocks. Integrity of the one or more incompressible blocks may then be verified by comparing the first tag and the third tag.

When IPM for a plurality of incompressible blocks needs to be generated and incorporated into the third tag, state information generated while processing one incompressible block needs to be stored and made available for use when processing the next incompressible block. To facilitate this, a cache memory 118 may be included in the processor 102. The processor 102 may then be configured to store state information such as a message authentication code or other IPM, in the cache memory 118 where it will be readily available to the processor 102 when processing the following incompressible block.

Data leaving an isolated domain such as an enclave or trusted execution environment (TEE), must be protected to preserve its confidentiality and integrity. Data protection is also required for removable storage media such as hard drives or USB sticks. Protected storage, such as memory isolated within an enclave or TEE, is referred to herein as secure storage. Storage that is not protected, such as removable media or memory associated with an unprotected execution environment, is referred to herein as insecure storage. The exemplary apparatus 100 includes a secure storage 106 and an insecure storage 108, and the processor 102 is configured to read and write incompressible blocks and compressible blocks from and to the secure storage 106 and to write and read cyphertexts to and from the insecure storage 108. The processor 102 protects blocks as they are moved out of secure storage 108 and de-protects cyphertexts when moving data from insecure storage 108 to secure storage 106.

The process of de-protection requires that compressed blocks be identified and differentiated from incompressible blocks. Certain values, referred to herein as magic numbers, rarely appear in incompressible data. In one embodiment, a magic number may be included in the header, such as in the compression information portion of the header, and the processor 102 may be configured to differentiate a compressed block from an incompressible block based at least in part on the magic number.

In one embodiment of the apparatus 100, the secure memory 104 is isolated within a secure enclave, and the processor 102 is configured to protect the incompressible block and the compressible block, based on the above-described protection methods, when moving the incompressible block and the compressible block outside a boundary of the secure enclave. When the data is needed, the processor 102 may de-protect the blocks and write them back to secure storage. The ability to fully implement the herein described protection and de-protection techniques in software makes them particularly advantageous for data migration in secure enclaves. Figure 4 illustrates a flow chart of an exemplary method 400 for protecting blocks incorporating aspect of the disclosed embodiments. The exemplary method 400 is configured to protect blocks in situ without any data expansion. The exemplary method 400 may also be fully implemented in software thereby providing an efficient and transparent protection mechanism. The exemplary method 400 is appropriate for use in the exemplary apparatus 100 described above and with respect to Figure 1.

Processing begins by reading 402 a block. The block may be read from any appropriate type of secure storage. Incompressible blocks are processed differently than compressible blocks and a check 406 is performed on the block to determine whether the block is compressible or incompressible. Compressibility may be determined in any appropriate fashion where a compressible block yields sufficient free-space to store both the compressed block and the header in one block, and an incompressible block yields a free-space smaller than the size of the header. When a block is determined to be incompressible 424, a tag is generated 416 based on the incompressible block. Generation of the tag 416 for a series of multiple incompressible blocks includes updating a previously generated tag to include IPM for the incompressible block currently being protected. A tag or IPM that is adapted to provide integrity protection for one or more incompressible blocks is referred to herein as multi-block IPM (MIPM) or a multiblock tag. Note, a multi-block tag may be adapted to incorporate IPM for any number of one or more incompressible blocks.

Confidentiality of the incompressible block is provided by encrypting 418 the incompressible block to produce a first cyphertext. The cyphertext may then be safely stored 420 in insecure storage. Only authorized entities have access to the decryption key thereby ensuring confidentiality of the protected block.

When a compressible block is detected 426, the block is compressed 404 to produce a compressed block and a free-space, where a size of the free-space is not less than the size of the header. The free-space is therefore sufficient to store the desired header information. A tag is produced 408 based on the compressed block for use when verifying integrity of the block. The produced tag 408 includes IPM for the current compressed block and is referred to herein as a local tag. The local tag and the multi-block tag are combined to generate 412 a header. The header is combined with or added to 414 the compressed block, and the header and compressed block are encrypted 418 to produce a second cyphertext. The second cyphertext may then be safely stored 420 in insecure storage.

The exemplary process 400 is repeated 422 until all blocks have been protected.

In certain embodiments, a plurality of incompressible blocks will be encountered in succession. When this occurs the multi-block tag can be updated 416 to include IPM for each successive incompressible block in the plurality of incompressible blocks. The resulting multi-block tag may then be included 412 in the header and used to verify integrity of the plurality of blocks while de-protecting the cyphertexts.

In one embodiment the exemplary method 400 is adapted to generate 410 compression information, where the compression information includes information useful when decompressing the compressed block. The compression information may include any desired information related to generation 404 of the compressed block, such as compression parameters and an indication of the compression algorithm used to compress the compressible block. Including 412 the compression information in the header ensures the compression information will be available during de-protection of the block.

Figure 5 illustrates a flow chart of an exemplary method 500 for de-protecting cyphertexts incorporating aspects of the disclosed embodiments. The exemplary method 500 is appropriate for use in the exemplary apparatus 100 for de-protecting cyphertexts generated by the abovedescribed protection method 400.

The exemplary method 500 begins by reading 502 a cyphertext from insecure storage. The cyphertext is decrypted 504 to recover a plaintext block which is checked 506 to identify it as either a recovered incompressible block or a recovered compressed block. Identification 506 may be performed in any appropriate fashion such as by examining a magic number incorporated into the header.

When the plaintext block is identified 526 as an incompressible block a multi-block tag or MIPM is generated 508 based on the recovered incompressible block. A new multi-block tag may be generated 508 when this is the first incompressible block identified. When the current incompressible block is preceded by another incompressible block, generation 508 of the multiblock tag includes updating a previously generated multi-block tag to include IPM for the incompressible block currently being processed.

When the plaintext block is identified 528 as containing a recovered compressed block and a header, a local tag is generated 510 based on the recovered compressed block. A multi-block tag is extracted from the header and compared 512 with the multi-block tag generated 508 based on one or more previously processed incompressible blocks. When the comparison 512 is unsuccessful, an integrity issue is indicated 514 and appropriate action may be taken.

When the comparison 512 is successful, integrity of the one or more incompressible blocks on which the multi-block tag was based is verified, and the exemplary method 500 proceeds to validate 516 the recovered compressed block. The generated 510 local tag is compared 516 to the local tag included in the header. When the comparison 516 is unsuccessful, integrity of the recovered compressed block is compromised, and appropriate action may be taken 518.

When the comparison 516 is successful integrity of the recovered compressed block is verified 520 and the recovered compressed block is decompressed 522 to obtain the original compressible block. The compressible block may then be stored 510 in secure storage such as storage isolated in an enclave or other trusted execution environment.

The exemplary method 500 is then repeated 524 until all blocks have been de-protected.

As described above, in certain embodiments, compression information is included in the header. The compression information may be extracted from the header and used to guide decompression 522 of the compressed block.

Thus, while there have been shown, described, and pointed out, fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that various omissions, substitutions and changes in the form and details of devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Further, it is expressly intended that all combinations of those elements, which perform substantially the same function in substantially the same way to achieve the same results, are within the scope of the invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims

1. An apparatus (100) comprising a processor (102) and a memory (104), wherein the processor

(102) is configured to protect an incompressible block and a compressible block, and the protecting comprises: generating a first tag based on the incompressible block; encrypting the incompressible block to produce a first cyphertext; compressing the compressible block to produce a compressed block and a free- space, wherein a size of the free-space is not less than a size of a header; generating a second tag based on the compressed block; generating the header, wherein the header comprises the first tag, and the second tag; combining the header with the compressed block; and encrypting the compressed block along with the header to produce a second cyphertext.

2. The apparatus (100) according to claim 1 wherein the processor (102) is configured to generate a compression information, the compression information comprising compression parameters and an indication of a compression algorithm used to compress the compressible block, and wherein the header further comprises the compression information.

3. The apparatus (100) according to any one of the preceding claims wherein the incompressible block comprises a plurality of incompressible blocks, and the first tag is generated based on the plurality of incompressible blocks.

4. The apparatus (100) according to any one of the preceding claims wherein the processor

(102) is configured to select a compression algorithm from a prioritized list of compression algorithms, wherein the compression algorithm is selected to provide the least costly compression method that yields a free-space that is not less than the size of the header.

5. The apparatus (100) according to claim 4 wherein the prioritized list of compression algorithms comprises one or more of a 0-replacement algorithm, a run-length encoding algorithm, a move-to-front algorithm, an interpolative coding algorithm, and an ExpGolomb algorithm.

6. The apparatus (100) according to any one of the preceding claims wherein the processor

(102) is further configured to de-protect the first cyphertext and the second cyphertext, and wherein the de-protecting comprises: decrypting the first cyphertext to recover the incompressible block; generating a third tag based on the recovered incompressible block; decrypting the second cyphertext to recover the compressed block and the header; generating a fourth tag based on the recovered compressed block; verifying an integrity of the recovered incompressible block by comparing the third tag with the first tag; verifying an integrity of the recovered compressed block by comparing the fourth tag with the second tag; when the integrity of the recovered incompressible block and the integrity of the recovered compressible block are successfully verified, decompressing the recovered compressed block based on the compression information to produce the compressible block.

7. The apparatus (100) according to claim 6 wherein the recovered incompressible block comprises a plurality of recovered incompressible blocks, and the processor (102) is configured to generate the third tag based on the plurality of incompressible blocks.

8. The apparatus (100) according to claim 7 wherein the processor (102) comprises a cache memory (118), and wherein the processor (102) is configured to store a message authentication code state in the cache memory (118) while generating the third tag.

9. The apparatus (100) according to any one of the preceding claims, wherein the apparatus

(100) further comprises a secure storage (106) and an insecure storage (108), and the processor (102) is configured to read and write the incompressible block and the compressible block from and to the secure storage (106), and to write and read the first cyphertext and the second cyphertext to and from the insecure storage (108).

10. The apparatus (100) according to any one of the preceding claims wherein the incompressible block and the compressible block comprise a block size corresponding to a storage unit size of one or more of the secure storage (106) and the insecure storage (108).

11. The apparatus (100) according to any one of the preceding claims wherein the compression information comprises a magic number, and the processor (102) is configured to differentiate a compressed block from an incompressible block based at least in part on the magic number.

12. The apparatus (100) according to any one of the preceding claims, wherein the secure memory (104) is isolated within a secure enclave, and wherein the processor (102) is configured to protect the incompressible block and the compressible block when moving the incompressible block and the compressible block outside a boundary of the secure enclave.

13. A method (400) for protecting an incompressible block and a compressible block, the method (400) comprising: identifying (406) the incompressible block; generating (416) a first tag based on the incompressible block; encrypting (418) the incompressible block to produce a first cyphertext; compressing (404) the compressible block to produce a compressed block and a free-space, wherein a size of the free-space is not less than a size of a header; generating (408) a second tag based on the compressed block; generating (412) the header wherein the header comprises the first tag, and the second tag; adding (414) the header to the compressed block; and encrypting (418) the compressed block along with the header to produce a second cyphertext.

14. The method (400) according to claim 13 wherein the method (400) comprises generating (410) a compression information, the compression information comprising compression parameters and an indication of a compression algorithm used to compress the compressible block, and wherein the header further comprises the compression information.

15. The method (400) according to any one of claims 13 or 14 wherein the incompressible block comprises a plurality of incompressible blocks, and wherein generating (408) the first tag comprises generating the first tag based on the plurality of incompressible blocks.

16. A method (500) for de-protecting a first cyphertext and a second cyphertext, the method (500) comprising: decrypting (504) the first cyphertext to recover a first plaintext; identifying (506) the first plaintext as a recovered incompressible block; generating (508) a third tag based on the recovered incompressible block; decrypting (504) the second cyphertext to recover a second plain text; identifying (506) the second plain text as a recovered compressed block and a header, wherein the header comprises a compression information, a first tag corresponding to the incompressible block, and a second tag corresponding to the compressed block; generating (510) a fourth tag based on the recovered compressed block; verifying (512) an integrity of the recovered incompressible block by comparing the third tag with the first tag; verifying (520) an integrity of the recovered compressed block by comparing the fourth tag with the second tag; when (520) the integrity of the recovered incompressible block and the integrity of the recovered compressed block are successfully verified, decompressing (522) the recovered compressed block based on the compression information to produce a recovered compressible block.

17. The method (500) according to claim 16 wherein the recovered incompressible block comprises a plurality of recovered incompressible blocks, and wherein generating (508) the third tag comprises generating the third tag based on the plurality of recovered incompressible blocks.