Project Topics
Get Complete Project Material File(s) Now! »
Global Authentication and Incremental Cryptography
Global authenticity is a strong security notion that aims at protecting all the local tags from tampering. A simple solution is to store all these tags in persistent secure memory, which means the adversary cannot tamper with it.
Secure Memory (SM). Obviously, such a component is not an accessible part of the disk otherwise downgrade attacks are still applicable. Now, we will assume that such memory exists otherwise replay attacks cannot be prevented in the context of full disk encryption [HGX+09, BPM18] and also in the context of secure cloud storage with block-level encryption [OR05, CJK+17]. Disk and cloud storage are similar from a theoretical point of view in the sense that the server can be seen as a big remote disk. These two use cases are different; nonetheless the data authenticity problem for data stored in a physical disk or in a distant disk (cloud) can be solved similarly. For disk protection, we can consider a Secure Element11 as a SM but it can store only a limited amount of data typically few kilobytes to few megabytes[STM17]. Whereas for cloud storage, the SM can be associated with a dedicated client local storage where it is possible to store data that cannot be tampered with by the server. In this case, the SM can be a whole disk partition that the local OS protects from any server access, yielding in few gigabytes of ”secure memory” size.
Once again, the naive idea is to compute a global tag over all the local tags. Then reading a sector will lead re-computation over all the local tags which is too much time-consuming.
FADE Model. Once more, we have a different model that is slightly deviating from the ADE one called the Fully Authenticated Disk Encryption (FADE) where the adversary has the possibility to perform any modification on the disk. It breaks data authentication if it succeeds to build a forge for a sector s different from the last legitimate one. In this model, the adversary can attempt replay attacks.
Global MACs. To be secure in the FADE model, a global MAC is needed, and it should have specific properties to be effective in the FDE context.
-Security: It has to guarantee the authenticity of the local tags.
-Speed: It has to be fast for tag generation and tag verification. It has to minimize cryptographic operations but also the added read and write access to the disk: tag generation and verification must be relative to a data unit.
-Locality: If the verification fails, the index of tampered sectors should be easy to find.
-Minimal storage in the disk: If additional data has to be stored in the disk it should be as short as possible to lose a minimum space in the disk.
-Minimal storage in secure memory As argued above, a global tag has to be stored in secure memory that has limited storage space.
Incremental Cryptography.
Incremental MACs can fulfil some properties above. Incremental cryptography was introduced by Bellare, Goldreich and Goldwasser in 1994 [BGG95] and it is an attractive feature that enables to efficiently update a cryptographic output like a ciphertext, a signature or an authentication tag after modifying the corresponding input. A MAC can be incremental regarding some update operations like replacing, deleting or inserting a block in the input. In our case, the input is the concatenation of the sector local tags computed with a classical MAC e.g, not an incremental MAC then for each modification in a sector; the local tag will be recomputed, and the global tag (output of incremental MAC) will be updated.
Figure 2.11: Overview of incremental replace operation. The function fK denotes the MAC primitive. The inputs τ1, τ2, τ3 give the tag τ. After replacing the value τ1 by τ4, the tag τ is updated with τ0.
Usually, this efficiency comes from some independent MAC over all the inputs (values pi in Figure 2.11) and the resulting output block are combined to obtain the global tag τ. This independent processing seems to fit the independence of the disk sectors: as the sectors are modified independently, we can imagine a root tag τ for all the disk that is updated for each sector modification without recomputing the root tag from scratch (otherwise it would be inefficient). A disk is a fixed number of sectors, and local tags depend on the sector number so having an incremental MAC regarding the replace operation only is sufficient. The chaining Xor-Scheme [BGG95][KV18], Xor-MAC [BGR95a] and GMAC [KVW04] and Merkle tree [BGG95] are incremental MACs. These algorithms use a keyed function fK 12 and, they are compared in table 2.1 with regard to the computational time of their tag generation algorithm, the replace update operation and the tag verification algorithm. The table gives the number of calls to fK for a disk composed of n sectors which means that the input of the tagging algorithm is the concatenation of the sector local authentication tags. In the following, log is for binary logarithm. For n inputs, the Xor-Scheme and the Xor-MAC have a constant time replacing operation (respectively 4 and 2 calls to fK ) and the storage cost is only a tag size. The main drawback is the verification cost: to verify the authenticity of 1 sector tag; it requires n calls to fK . Merkle tree is the only incremental scheme that has the locality property and a trade-off between replace and verify operation delays. The counterpart is that it requires more storage space, but it is not necessary to store the entire tree. In the next section, the Merkle tree storage will be discussed in details.
Merkle Tree
A Merkle tree is an authentication data structure where leaves are the values to protect, and each node is the MAC13 of the concatenation of its children. In the following, Merkle trees are binary trees which means that each node is the MAC of its two children. This construction is used to ensure data authenticity at block level [OR05, HGX+09, HWF15, dm-19b], in cloud storage context [OR07, HPPT08, CJK+17] and at file level [RCPS07] due to its incremental and locality properties.
This estimation is given for a perfect binary tree. A tree is said to be a perfect binary tree when all its nodes have two children, and all leaves have the same depth. So the number of actual data is exactly 2n where n is an integer. In this paper, all the Merkle tree storage cost are computed according to a number of leaves (tags) equal to a power of 2 e.g. where n = 2n0 and n0 = log(n). The entire tree consists of 2n0 − 1 nodes. Otherwise, the value n0 can be set to log(n) + 1 which is the worst case e.g. non-optimized tree. Let L be the output size of the MAC algorithm fK used to compute the Merkle tree nodes. Then storing an entire Merkle tree takes (2n0 − 1)L bits.
There are different memories where it can be stored: the SM, the disk and the RAM. But in any case, a copy of the trusted root has to be stored in the SM. This value must not be tampered with in order to recompute the path from the sector local tag to the root and check the obtained root and the stored one. To simplify the analysis, we distinguish two ways of storing the tree: either it is entirely stored in the same memory which is said to be a stand-alone storage, or the tree is split into different memories which is said to be an hybrid storage. It is possible to store some strategic nodes and to recompute the corresponding subtrees when needed.
The nowadays RAM modules can store a large amount of data; typically between 4 GB and 16 GB. In addition to current computation data, the RAM could store a part of the Merkle tree. In the following, an estimation of the update/verify times of a sector and, the storage cost in the different memories is given depending on the storage configurations. Some of the following solutions are suitable for disk protection but, once again it depends on the device: for a laptop, the disk size is in the range of gigabyte or terabyte, the RAM size is rarely larger than 32 GB and is in average around 8 GB. The secure memory is usually only few kilobytes. The access latencies of the different memories are also a parameter to take into account.
Stand-alone Storage
Table 2.2 gives 5 possibilities for Merkle tree storage where the entire Merkle tree is stored in the SM, the disk or the RAM.
• S1: The entire Merkle tree is stored in the SM and for each read and write operation, the update/verify operation on the Merkle tree costs n0 calls fK . This solution does not use disk and RAM storage but the update/verify which has a reasonable cost. If it is possible to store 2n0 − 1 tags then it should be possible to store 2n0 which corresponds to solution S1’. In this case, all the local tags can be stored in the SM and, as it is assumed that this memory is tamper proof, the global authentication scheme is no longer needed: the local tags are stored directly in SM. Then the Merkle tree is not needed any more. If the SM is big enough, this solution should be considered otherwise the following possibilities, where only a small value (the root) is stored in SM, are more suitable.
• S2: The only value stored is the Merkle tree root and it is stored in the SM. The advantage is that the storage on the disk, in the SM and RAM is minimized but the update/verify cost is the worst: the entire Merkle tree has to be recomputed for each update/verify operation. For this reason, this solution seems to be unsuitable for disks.
• S3: This solution considers a context where the RAM is big enough to store the entire Merkle tree and operates in rated conditions. The access time to Merkle tree nodes in the RAM is smaller than in the disk but the counterpart is that the Merkle tree will not be maintained when the system is switched off. It has to be recomputed each time the system is switched on. This solution could be interesting if saving disk storage is a priority. In fact, it stores only the root in SM and no additional data in the disk. The update/verify operation cost is reasonable but a re-computation delay due to the volatility of the RAM is added.
• S4: This solution has the same settings than S3 except that the Merkle tree is not stored in RAM but in the disk. It has the advantage to remove the re-computation delay, but this time the additional storage in the disk is the entire Merkle tree size. Moreover, the time to read and write a node will be larger as it is stored in the disk. Unsurprisingly, this solution could be implemented in an optimized manner by some developers as solution S5.
• S5: This solution combines solutions S3 and S4: the tree is stored in the disk and also in the RAM. Each time the device is switched on, the Merkle tree is copied from the disk to the RAM which avoids the re-computation delay of solution S3. This solution is the most efficient from a speed point of view.
For a reasonable amount of data, solution S1’ can be considered for cloud storage as few gigabytes can be stored in the client side, but it seems unpractical for a stand-alone disk. Solution S5 stores only the root in the SM and is the quickest solution described above, which makes it the most suitable for stand-alone disk.
Table 2.3: Estimation of Stand-alone storage of Merkle tree where n = 228 and L = 32 Bytes Discussion. Table 2.3 gives the Merkle tree storage cost in RAM, in the disk and the SM with the same settings than in section 2.3.1.2. As explained in the analysis of S2, the update and verify operations cost a large amount of calls to the function fK . The same problem will emerge each time the device is switched on for solution S3 due to storage in RAM. Solutions S1 and S1’ are not suitable for the rather small sized SM we discussed in section 2.3.2. Unsurprisingly, solution S5 seems to be the most suitable for disk protection.
Hybrid Storage
Table 2.4 presents possibilities where the Merkle tree nodes of level m, where m ≤ n0, are stored. Here, the performance depends on the choice of m and, it has to be instantiated in table 2.4. The optimum value of m depends on many factors: the disk, the SM and the RAM sizes, the CPU, the cryptographic algorithms etc. Due to this variety of factors, this analysis is only theoretical: it provides insights about the main tendencies of each implementation strategy. It would be nonetheless interesting to test these solutions in different devices to adjust the level m and compare their real performances.
• H1: This solution minimizes the storage in SM by storing the Merkle tree root only. The top of the Merkle tree, from the root to level m, is stored in the disk. For each update/verify operation, recomputing the corresponding subtree costs 2m − 1 calls to fK and the update/verify of the top of the tree cost m calls to fK . If a verification fails, it will not be possible to find exactly which sector was tampered with, in the best case, only the node at level m can be given as an information to the user.
• H2: The nodes at the level m (2m nodes) are stored in the SM. Here, these nodes do not need data authenticity check; they are assumed to be authentic as they are stored in the SM. For each update, the needed subtree is recomputed which costs 2n0−m − 1 calls to fK . Here, the SM has to store 2mL bits. Depending on the value m and the SM size, it might be possible for a disk. For instance, if the SM can store 1 MB and the L = 256 bits, then the maximum value of m is 12.
• H3: The nodes of the level m are stored in the SM and, the m subtrees are stored in the RAM. Each update operation costs going through the subtree, which requires n0 − m calls. Storage in the RAM involves a re-computation time when the device is switched on.
• H4: The nodes of the level m are stored in the SM and all the subtrees (m) are stored in the disk. Unlike, the previous solution, accessing tree nodes in the disk takes more time.
• H5: The Merkle tree is split between all the memories: the root in SM, the top in the disk and the corresponding subtrees in the RAM. Because of the storage in the RAM, a recomputing delay is added each time the device is switched off. The update/verify time is acceptable.
Table of contents :
Chapter 1 Introduction
1.1. The calcium carbonate system
1.2. Calcium carbonate mineral nucleation pathways
1.3. Classical Nucleation Theory
1.4. Heterogeneous nucleation
1.5. Multistep nucleation pathways
1.6. The amorphous precursor strategy
References
Chapter 2 State of the art and research questions
2.1. Heterogeneous nucleation of CaCO3
2.1.1. Thermodynamics of heterogeneous nucleation
2.1.2. Heterogeneous nucleation: A molecular view of the electrolyte-substrate interface
2.2. Surface hydrophobicity and properties of interfacial water
2.3. Amorphous calcium carbonate: an intermediate in the CaCO3 crystallization processes
2.3.1. Structure of amorphous calcium carbonate and polyamorphism
2.3.2. Water as structural component
2.3.3. Dynamics of structural water and kinetic control of additives
2.4. Summary of research questions and hypotheses
2.5. Dissertation organization
References
Chapter 3 Fundamentals: experimental and theoretical methods
3.1. X-ray Photon Correlation Spectroscopy (XPCS)
3.2. Near-Ambient Pressure X-ray Photoelectron Spectroscopy (NAP-XPS)
3.2.1. Electronic structure of atoms
3.2.2. General principles
3.2.3. Near-Ambient Pressure X-ray Photoelectron Spectroscopy and its application
3.3. Grazing-incidence Small Angle X-ray Scattering
3.3.1. General principles
3.3.2. Data analysis
3.4. Inelastic Incoherent Neutron Scattering (IINS)
3.4.1. Inelastic neutron scattering (INS)
3.4.2. Inelastic Incoherent Neutron Scattering (IINS) as a probe of hydrogen dynamics
3.5. Molecular Dynamics simulations
3.6. Bond-valence model
References
Chapter 4 Heterogeneous nucleation of calcium carbonate: effect of surface hydrophobicity
4.1. Introduction
4.2. Materials and Methods
4.2.1. Sample preparation
4.2.2. In situ time-resolved Grazing-Incidence Small Angle X-ray Scattering (GISAXS)
4.2.3. Ex situ heterogeneous nucleation experiments
4.3. Results
4.3.1. In situ time-resolved GISAXS
4.3.2. Ex situ observation by Atomic Force Microscopy
4.3.3. Ex situ observation by ATR-FTIR
4.4. Discussion
4.4.1. Effect of surface hydrophobicity on ’ values
4.4.2. Surface hydrophobicity controls the kinetic persistence of ACC
4.4.3. Can there be thermodynamic contributions to the stability of ACC controlled by surface hydrophobicity?
4.4.4. Limitation in the application of CNT
4.5. Conclusion
Supporting information
References
Chapter 5 Surface hydrophobicity and properties of interfacial water
5.1. Introduction
5.2. Materials and Methods
5.2.1. Phlogopite mica
5.2.2. Near-ambient pressure X-ray Photoelectron Spectroscopy (NAP-XPS)
5.2.3. Molecular dynamics simulations
5.3. Results
5.3.1. NAP-XPS
5.3.2. Molecular dynamics simulations
5.4. Discussion
5.4.1. Oxygen species of phlogopite mica
5.4.2. Effects of surface hydration on bonding environments
5.4.3. Detailed picture of surface hydration: what makes surface hydrophobic and what initiates water adsorption?
5.4.4. Sensitivity of classical MD simulation on predicting the shifts in binding energies
5.5. Conclusion
Supporting Information
References
Chapter 6 Nanoscopic dynamics of amorphous calcium carbonate: understanding the mechanisms controlling the crystallization kinetics
6.1. Introduction
6.2. Materials and Methods
6.2.1 Sample preparation
6.2.2. Inelastic incoherent neutron scattering (IINS)
6.2.3. X-ray photon correlation spectroscopy (XPCS)
6.2.4. Thermogravimetric and calorimetric analyses
6.3. Results
6.3.1. High-energy water dynamics probed by IINS
6.3.2. Ionic dynamics probed by XPCS
6.4. Discussion
6.4.1. The effects of Mg2+ on the water dynamics
6.4.2. Amorphous carbonates as highly dynamics soft matter systems
6.4.3. Linking solid state dynamics and crystallization kinetics
6.4.4. Aging dynamics
6.5. Conclusions
Chapter 7 Conclusions
7.1. Heterogeneous nucleation of calcium carbonate: effect of surface hydrophobicity
7.2. Surface hydrophobicity and properties of interfacial water
7.3. Nanoscopic dynamics of amorphous calcium carbonate: understanding the mechanisms controlling the crystallization kinetics
7.4. New hypotheses
7.4.1. Multistep heterogeneous nucleation pathway
7.4.2. Coexistence of accelerated dynamics and stiff hydrogen bond networks
