Joomla! Joomla!
DiceLock for Linux

DiceLock-x so DiceLock cipher architecture implementation shared object library allows to work with memory that is kept in RAM, memory pages are locked in RAM and they are not swapped to hard disk.

DiceLock-x provides this feature through the use of PhysicalCryptoRandomStream class. PhysicalCryptoRandomStream objects can be employed to keep any kind of data like encryption symmetric keys, plaintexts, ciphertexts, hash digests, streams to be checked for randomness, etc.

C++ driver programs CheckDiceLockBaseAlgorithms-x, CheckDiceLockKeyModifiers-x, CheckDiceLockIndexed-x, CheckDiceLockDigested-x, CheckDiceLockIVIndexed-CBC-x, CheckDiceLockIVIndexed-CFB-x, CheckDiceLockIVIndexed-OFB-x, CheckDiceLockIVIndexed-noOM-x, CheckDiceLockIVDigested-CBC-x, CheckDiceLockIVDigested-CFB-x, CheckDiceLockIVDigested-OFB-x, CheckDiceLockIVDigested-noOM-x, CheckDiceLockXTSIndexedFull-x, CheckDiceLockXTSIndexedSector-x, CheckDiceLockXTSDigestedFull-x or CheckDiceLockXTSDigestedSector-x operate with both types of memory handlers (memory swapped to hard disk and memory pages locked). It's an option that allows to perform the same kind of tests with both memory types.

Unlike the use of DefaultCryptoRandomStream objects (which handle default memory management, memory pages can be swapped to hard disk) that can be used with any version or configuration of Linux, the use PhysicalCryptoRandomStream objects maybe limited to some versions and users logged in the operating systems.

For the purpose of DiceLock-x implementation validation all performed tests have been done under the root user, that is, the user with no limitations. This approach has been chosen because main focus of these tests is to verify that DiceLock-x implementation operates correctly and also because there exist a lot different Linux distributions and versions.

Iin order to use PhysicalCryptoRandomStream with any other kind of user, it must be taken into account that PhysicalCryptoRandomStream works on Linux mlock and munlock functions, and all restrictions and limitations applied to these functions apply to PhysicalCryptoRandomStream.

Extracted from Linux man-pages

mlock() lock part of the calling  process's virtual address space into RAM, preventing that memory from being paged to the swap area. munlock() perform the converse operation, respectively unlocking the part of the calling process's virtual address space, so that pages in the specified virtual address range may once more to be swapped out if required by the kernel memory manager. Memory locking and unlocking are performed in units of whole pages.

mlock() locks pages in the address range starting at addr and continuing for len bytes. All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. munlock() unlocks pages in the address range starting at addr and continuing for len bytes.  After this call, all pages that contain a part of the specified memory range can be moved to external swap space again by the kernel.

Memory locking has two main applications: real-time algorithms and high-security data processing. Cryptographic security software often handles critical bytes like passwords or secret keys as data structures. As a result of paging, these secrets could be transferred onto a persistent swap store medium, where they might be accessible to the enemy long after the security software has erased the secrets in RAM and terminated.  (But be aware that the suspend mode on laptops and some desktop computers will save a copy of the system's RAM to disk,  regardless of memory locks.)

Memory locks are not inherited by a child created via fork and are automatically removed (unlocked) during an execve or when the process terminates.

The memory lock on an address range is automatically removed if the address range is unmapped via munmap.

Memory locks do not stack, that is, pages which have been locked several times by calls to mlock() will be unlocked by a single call to munlock() for the corresponding range. Pages which are mapped to several locations or by several processes stay locked into RAM as long as they are locked at least at one location or by at least one process.

Limits and permissions

In Linux 2.6.8 and earlier, a process must be privileged  (CAP_IPC_LOCK) in order to lock memory and the RLIMIT_MEMLOCK soft resource limit defines a limit on how much memory the process may lock.

Since Linux 2.6.9, no limits are placed on the amount of memory that a privileged process can lock and the RLIMIT_MEMLOCK soft resource limit instead defines a limit on how much memory an unprivileged process may lock.