N. Provos. Encrypting virtual memory. In Proceedings of the 10th USENIX Security Symposium, pages 35--44, August 2000.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....applications often hold sensitive data in their address spaces. If any of this state is paged out to disk, it will be available to an attacker much as an unencrypted file system would be. Provos provides a system for protecting paging space using per page encryption keys with short lifetimes [26]. ZIA is complimentary to this system; ZIA protects file system state, while Provos system protects persistent copies of application address spaces. Several e#orts have used proximity based hardware tokens to detect the presence of an authorized user. Landwehr [16] proposes disabling hardware ....

N. Provos. Encrypting virtual memory. In Proceedings of the Ninth USENIX Security Symposium, pages 35--44, Denver, CO, August 2000.

....either they are carried or they are part of the surrounding infrastructure. As long as the token can be unobtrusively worn, it affords a greater degree of physical security. Transient Authentication has been applied to cryptographic file systems [6] and could be extended to protect swap space [23]. These provide a good first line of defense, protecting persistent storage from physical possession attacks. Unfortunately, they do not protect applications. An application that reads data from a cryptographic file system or receives data from a secure network connection [1, 29] holds that ....

....Authentication process, illustrating all of these principles, is shown in Figure 1. 4 Application Transparent Protection Applications store sensitive information, such as credit card numbers and passwords, in their virtual address space. Even with an encrypted file system [6] and swap space [23], the in memory portions of an applications address space vulnerable to attack. The memory 3 bus or chips may be probed by a knowledgeable attacker, or OS interfaces can be exploited to examine raw memory contents. This section describes a technique, called application transparent protection, ....

[Article contains additional citation context not shown here]

N. Provos. Encrypting virtual memory. In Proceedings of the Ninth USENIX Security Symposium, pages 35--44, Denver, CO, August 2000.

....then encrypts each inmemory page belonging to the process and erases the key. When the user returns, the system fetches the decryption key from the token and restores each page. The processes are restarted and the system continues without loss in performance. Combined with swap space protection [13], this mechanism fully protects virtual memory. We are currently implementing address space protection. There are two reasons why this brute force approach may not be desirable. First, completely suspending all applications even those without sensitive data is effective but indiscriminate. ....

N. Provos. Encrypting virtual memory. In Proceedings of the Ninth USENIX Security Symposium, pages 35--44, Denver, CO, August 2000.

....on the other hand, uses much simpler (and not scalable) location map organization and completely avoids building the Merkle tree. A number of file systems protect secrecy of files by encrypting them with a secret key [t, 25, 4, t0] Provos designed a similar protection for virtual mem ory pages [15]. Unlike GnatDb, such file systems pro vide only secrecy, but not tamper detection. Several file systems provide also tamper detection: Fu, Kaashoek and Mazieres designed Read only File System, SFSRO, which embeds a Merkle tree in the inode hierarchy [9] The root hash, which certifies the in ....

N. Provos. Encrypting virtual memory. In Proceedings of the 9th USENIX Security Symposium, August 2000. Denver, CO.

....original owner of a piece of data was after it has been transmitted within the system. Only a complete redesign of the operating system could make the export right enforceable in all cases. However, leakage of plain text to virtual memory can be prevented with only minor system modifications. [5] proposes to encrypt swap file data with a session key, which is discarded on system shut down, thus making the contents of the swap file unreadable. Introduce After creating a new encrypted file system, the owner is the only one who can issue key files to give additional users access to the ....

N. Provos. Encrypting Virtual Memory. USENIX Security Symposium. Denver, CO, August 2000

....perimeter. Even when the volatile memory lies within the security perimeter, it may be still paged to insecure stable storage by the virtual memory subsystem. Provos describes a mechanisms for securely paging to insecure stable storage by encrypting all pages swapped out to the stable storage [13]. The encryption key, which is stored in pinned volatile memory, is randomly generated by the virtual memory subsystem and destroyed once all references to the page are removed (i.e. all processes using that page terminate) A solution that also detects tampering would be to swap pages out to any ....

N. Provos. Encrypting virtual memory. In Proceedings of the 9th USENIX Security Symposium, August 2000. Denver, CO. 10

....whenever the secret is needed. Keeping the secret information inside a process user memory area does not matter because the user memory area is isolated from other processes. The other processes cannot access the secret information even when that process gains the root or super user privilege. In [10], Niels Provos pointed out the possibility of being revealed of the secret information stored at the user memory area of a running process if the secret information is swapped out 1 The information such as login password, pass phrase, or credit card numbers, etc. to the backing store. But, the ....

....solution for this problem is to hard code the secret information inside 2 The mlock( and mlockall( system calls are available. 3 Of course, the root or the super user privilege is needed to call these system calls successfully. For the normal user processes, the swap encryption proposed in [10] would be a great help. into the CGI application program le. The secret information is loaded into the process user memory area when the program is executed. But, if the secret information is hard coded inside into the application program le, it can be easily discovered by the attacker. As a ....

Niels Provos, \Encrypting Virtual Memory," In Proceedings of the 9th USENIX Security Symposium, August 2000.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the 10th USENIX Security Symposium, pages 35--44, August 2000.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the 9th USENIX Security Symposium, pages 35--44. USENIX Association, Aug. 2000. Denver, CO.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the Ninth USENIX Security Symposium, pages 35--44, Denver, CO, August 2000.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the 10th USENIX Security Symposium, pages 35--44, August 2000.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the 9th USENIX Security Symposium, August 2000.

No context found.

N. Provos. Encrypting virtual memory. In Proceedings of the 9th USENIX Security Symposium, pages 35--44. USENIX Association, Aug. 2000. Denver, CO.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC