| 1 |
commit: 7dd55a565f006fb64d8040395ea4ba408e13c9a3 |
| 2 |
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be> |
| 3 |
AuthorDate: Mon Jul 30 19:23:31 2012 +0000 |
| 4 |
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be> |
| 5 |
CommitDate: Mon Jul 30 19:23:31 2012 +0000 |
| 6 |
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=7dd55a56 |
| 7 |
|
| 8 |
Add in previous on integrity concepts |
| 9 |
|
| 10 |
--- |
| 11 |
html/integrity/concepts.html | 463 ++++++++++++++++++++++++++++++++++++++++++ |
| 12 |
1 files changed, 463 insertions(+), 0 deletions(-) |
| 13 |
|
| 14 |
diff --git a/html/integrity/concepts.html b/html/integrity/concepts.html |
| 15 |
new file mode 100644 |
| 16 |
index 0000000..22b50d9 |
| 17 |
--- /dev/null |
| 18 |
+++ b/html/integrity/concepts.html |
| 19 |
@@ -0,0 +1,463 @@ |
| 20 |
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| 21 |
+<html lang="en"> |
| 22 |
+<head> |
| 23 |
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| 24 |
+<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css"> |
| 25 |
+<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon"> |
| 26 |
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website"> |
| 27 |
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums"> |
| 28 |
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla"> |
| 29 |
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages"> |
| 30 |
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives"> |
| 31 |
+<title>Gentoo Linux Documentation |
| 32 |
+-- |
| 33 |
+ Integrity - Introduction and Concepts</title> |
| 34 |
+</head> |
| 35 |
+<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0"> |
| 36 |
+<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr> |
| 37 |
+<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr> |
| 38 |
+<td width="99%" class="content" valign="top" align="left"> |
| 39 |
+<br><h1>Integrity - Introduction and Concepts</h1> |
| 40 |
+<form name="contents" action="http://www.gentoo.org"> |
| 41 |
+<b>Content</b>: |
| 42 |
+ <select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. It is about trust</option> |
| 43 |
+<option value="#doc_chap2">2. Hash results</option> |
| 44 |
+<option value="#doc_chap3">3. Hash-based Message Authentication Codes</option> |
| 45 |
+<option value="#doc_chap4">4. Using private/public key cryptography</option> |
| 46 |
+<option value="#doc_chap5">5. Trust chain</option> |
| 47 |
+<option value="#doc_chap6">6. An implementation: the Trusted Computing Group functionality</option></select> |
| 48 |
+</form> |
| 49 |
+<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1. |
| 50 |
+ </span>It is about trust</p> |
| 51 |
+<p class="secthead"><a name="doc_chap1_sect1">Introduction</a></p> |
| 52 |
+<p> |
| 53 |
+Integrity is about trusting components within your environment, and in our case |
| 54 |
+the workstations, servers and machines you work on. You definitely want to be |
| 55 |
+certain that the workstation you type your credentials on to log on to the |
| 56 |
+infrastructure is not compromised in any way. This "trust" in your environment |
| 57 |
+is a combination of various factors: physical security, system security patching |
| 58 |
+process, secure configuration, access controls and more. |
| 59 |
+</p> |
| 60 |
+<p> |
| 61 |
+Integrity plays a role in this security field: it tries to ensure that the |
| 62 |
+systems have not been tampered with by malicious people or organizations. And |
| 63 |
+this tamperproof-ness extends to a wide range of components that need to be |
| 64 |
+validated. You probably want to be certain that the binaries that are ran (and |
| 65 |
+libraries that are loaded) are those you built yourself (in case of Gentoo) or |
| 66 |
+were provided to you by someone (or something) you trust. And that the Linux |
| 67 |
+kernel you booted (and the modules that are loaded) are those you made, and not |
| 68 |
+someone else. |
| 69 |
+</p> |
| 70 |
+<p> |
| 71 |
+Most people trust themselves and look at integrity as if it needs to prove that |
| 72 |
+things are still as you've built them. But to support this claim, the systems you |
| 73 |
+use to ensure integrity need to be trusted too: you want to make sure that |
| 74 |
+whatever system is in place to offer you the final yes/no on the integrity only |
| 75 |
+uses trusted information (did it really validate the binary) and services (is it |
| 76 |
+not running on a compromised system). To support these claims, many ideas, |
| 77 |
+technologies, processes and algorithms have passed the review. |
| 78 |
+</p> |
| 79 |
+<p> |
| 80 |
+In this document, we will talk about a few of those, and how they play in the |
| 81 |
+Gentoo Hardened Integrity subprojects' vision and roadmap. |
| 82 |
+</p> |
| 83 |
+<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2. |
| 84 |
+ </span>Hash results</p> |
| 85 |
+<p class="secthead"><a name="doc_chap2_sect1">Algorithmically validating a file's content</a></p> |
| 86 |
+<p> |
| 87 |
+Hashes are a primary method for validating if a file (or other resource) has |
| 88 |
+not been changed since it was first inspected. A hash is the result of a |
| 89 |
+mathematical calculation on the content of a file (most often a number or |
| 90 |
+ordered set of numbers), and exhibits the following properties: |
| 91 |
+</p> |
| 92 |
+<ul> |
| 93 |
+ <li> |
| 94 |
+ The resulting number is represented in a <span class="emphasis">small (often fixed-size) length</span>. |
| 95 |
+ This is necessary to allow fast verification if two hash values are the same |
| 96 |
+ or not, but also to allow storing the value in a secure location (which is, |
| 97 |
+ more than often, much more restricted in space). |
| 98 |
+ </li> |
| 99 |
+ <li> |
| 100 |
+ The hash function always <span class="emphasis">returns the same hash</span> (output) when the file it |
| 101 |
+ inspects has not been changed (input). Otherwise it'll be impossible to |
| 102 |
+ ensure that the file content hasn't changed. |
| 103 |
+ </li> |
| 104 |
+ <li> |
| 105 |
+ The hash function is fast to run (the calculation of a hash result does not |
| 106 |
+ take up too much time or even resources). Without this property, it would |
| 107 |
+ take too long to generate and even validate hash results, leading to users |
| 108 |
+ being malcontent (and more likely to disable the validation alltogether). |
| 109 |
+ </li> |
| 110 |
+ <li> |
| 111 |
+ The hash result <span class="emphasis">cannot be used to reconstruct</span> the file. Although this is |
| 112 |
+ often seen as a result of the first property (small length), it is important |
| 113 |
+ because hash results are often also seen as a "public validation" of data |
| 114 |
+ that is otherwise private in nature. In other words, many processes relie on |
| 115 |
+ the inability of users (or hackers) to reverse-engineer information based on |
| 116 |
+ its hash result. A good example are passwords and password databases, which |
| 117 |
+ <span class="emphasis">should</span> store hashes of the passwords, not the passwords themselves. |
| 118 |
+ </li> |
| 119 |
+ <li> |
| 120 |
+ Given a hash result, it is near impossible to find another file with the |
| 121 |
+ same hash result (or to create such a file yourself). Since the hash result |
| 122 |
+ is limited in space, there are many inputs that will map onto the same |
| 123 |
+ hash result. The power of a good hash function is that it is not feasible to |
| 124 |
+ find them (or calculate them) except by brute force. When such a match is |
| 125 |
+ found, it is called a <span class="emphasis">collision</span>. |
| 126 |
+ </li> |
| 127 |
+</ul> |
| 128 |
+<p> |
| 129 |
+Compared with checksums, hashes try to be more cryptographically secure (and as |
| 130 |
+such more effort is made in the last property to make sure collisions are very |
| 131 |
+hard to obtain). Some even try to generate hash results in a way that the |
| 132 |
+duration to calculate hashes cannot be used to obtain information from the data |
| 133 |
+(such as if it contains more 0s than 1s, etc.) |
| 134 |
+</p> |
| 135 |
+<p class="secthead"><a name="doc_chap2_sect2">Hashes in integrity validation</a></p> |
| 136 |
+<p> |
| 137 |
+Integrity validation services are often based on hash generation and validation. |
| 138 |
+Tools such as <a href="http://www.tripwire.org/">tripwire</a> or <a href="http://aide.sourceforge.net/">AIDE</a> generate hashes of files and |
| 139 |
+directories on your systems and then ask you to store them safely. When you want |
| 140 |
+the integrity of your systems checked, you provide this information to the |
| 141 |
+program (most likely in a read-only manner since you don't want this list to |
| 142 |
+be modified while validating) which then recalculates the hashes of the files |
| 143 |
+and compares them with the given list. Any changes in files are detected and can |
| 144 |
+be reported to you (or the administrator). |
| 145 |
+</p> |
| 146 |
+<p> |
| 147 |
+A popular hash functions is SHA-1 (which you can generate and validate using the |
| 148 |
+<span class="code" dir="ltr">sha1sum</span> command) which gained momentum after MD5 (using <span class="code" dir="ltr">md5sum</span>) |
| 149 |
+was found to be less secure (nowadays collisions in MD5 are easy to generate). |
| 150 |
+SHA-2 also exists (but is less popular than SHA-1) and can be played with using |
| 151 |
+the commands <span class="code" dir="ltr">sha224sum</span>, <span class="code" dir="ltr">sha256sum</span>, <span class="code" dir="ltr">sha384sum</span> and |
| 152 |
+<span class="code" dir="ltr">sha512sum</span>. |
| 153 |
+</p> |
| 154 |
+<a name="doc_chap2_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0"> |
| 155 |
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.1: Generating the SHA-1 sum of a file</p></td></tr> |
| 156 |
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre> |
| 157 |
+~$ <span class="code-input">sha1sum ~/Downloads/pastie-4301043.rb</span> |
| 158 |
+6b9b4e0946044ec752992c2afffa7be103c2e748 /home/swift/Downloads/pastie-4301043.rb |
| 159 |
+</pre></td></tr> |
| 160 |
+</table> |
| 161 |
+<p class="secthead"><a name="doc_chap2_sect3">Hashes are a means, not a solution</a></p> |
| 162 |
+<p> |
| 163 |
+Hashes, in the field of integrity validation, are a means to compare data and |
| 164 |
+integrity in a relatively fast way. However, by itself hashes cannot be used to |
| 165 |
+provide integrity assurance towards the administrator. Take the use of |
| 166 |
+<span class="code" dir="ltr">sha1sum</span> by itself for instance. |
| 167 |
+</p> |
| 168 |
+<p> |
| 169 |
+You are not guaranteed that the <span class="code" dir="ltr">sha1sum</span> application behaves correctly |
| 170 |
+(and as such has or hasn't been tampered with). You can't use <span class="code" dir="ltr">sha1sum</span> |
| 171 |
+against itself since malicious modifications of the command can easily just |
| 172 |
+return (print out) the expected SHA-1 sum rather than the real one. A way to |
| 173 |
+thwart this is to provide the binary together with the hash values on read-only |
| 174 |
+media. |
| 175 |
+</p> |
| 176 |
+<p> |
| 177 |
+But then you're still not certain that it is that application that is executed: |
| 178 |
+a modified system might have you think it is executing that application, but |
| 179 |
+instead is using a different application. To provide this level of trust, you |
| 180 |
+need to get insurance from a higher-positioned, trusted service that the right |
| 181 |
+application is being ran. Running with a trusted kernel helps here (but might |
| 182 |
+not provide 100% closure on it) but you most likely need assistance from the |
| 183 |
+hardware (we will talk about the Trusted Platform Module later). |
| 184 |
+</p> |
| 185 |
+<p> |
| 186 |
+Likewise, you are not guaranteed that it is still your file with hash results |
| 187 |
+that is being used to verify the integrity of a file. Another file (with |
| 188 |
+modified content) may be bind-mounted on top of it. To support integrity |
| 189 |
+validation with a trusted information source, some solutions use HMAC digests |
| 190 |
+instead of plain hashes. |
| 191 |
+</p> |
| 192 |
+<p> |
| 193 |
+Finally, checksums should not only be taken on file level, but also its |
| 194 |
+attributes (which are often used to provide access controls or even toggle |
| 195 |
+particular security measures on/off on a file, such as is the case with PaX |
| 196 |
+markings), directories (holding information about directory updates such |
| 197 |
+as file adds or removals) and privileges. These are things that a program like |
| 198 |
+<span class="code" dir="ltr">sha1sum</span> doesn't offer (but tools like AIDE do). |
| 199 |
+</p> |
| 200 |
+<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3. |
| 201 |
+ </span>Hash-based Message Authentication Codes</p> |
| 202 |
+<p class="secthead"><a name="doc_chap3_sect1">Trusting the hash result</a></p> |
| 203 |
+<p> |
| 204 |
+In order to trust a hash result, some solutions use HMAC digests instead. An |
| 205 |
+HMAC digest combines a regular hash function (and its properties) with a |
| 206 |
+a secret cryptographic key. As such, the function generates the hash of the |
| 207 |
+content of a file together with the secret cryptographic key. This not only |
| 208 |
+provides integrity validation of the file, but also a signature telling the |
| 209 |
+verification tool that the hash was made by a trusted application (one that |
| 210 |
+knows the cryptographic key) in the past and has not been tampered with. |
| 211 |
+</p> |
| 212 |
+<p> |
| 213 |
+By using HMAC digests, malicious users will find it more difficult to modify |
| 214 |
+code and then present a "fake" hash results file since the user cannot reproduce |
| 215 |
+the secret cryptographic key that needs to be added to generate this new hash |
| 216 |
+result. When you see terms like <span class="emphasis">HMAC-SHA1</span> it means that a SHA-1 hash |
| 217 |
+result is used together with a cryptographic key. |
| 218 |
+</p> |
| 219 |
+<p class="secthead"><a name="doc_chap3_sect2">Managing the keys</a></p> |
| 220 |
+<p> |
| 221 |
+Using keys to "protect" the hash results introduces another level of complexity: |
| 222 |
+how do you properly, securely store the keys and access them only when needed? |
| 223 |
+You cannot just embed the key in the hash list (since a tampered system might |
| 224 |
+read it out when you are verifying the system, generate its own results file and |
| 225 |
+have you check against that instead). Likewise you can't just embed the key in |
| 226 |
+the application itself, because a tampered system might just read out the |
| 227 |
+application binary to find the key (and once compromised, you might need to |
| 228 |
+rebuild the application completely with a new key). |
| 229 |
+</p> |
| 230 |
+<p> |
| 231 |
+You might be tempted to just provide the key as a command-line argument, but |
| 232 |
+then again you are not certain that a malicious user is idling on your system, |
| 233 |
+waiting to capture this valuable information from the output of <span class="code" dir="ltr">ps</span>, etc. |
| 234 |
+</p> |
| 235 |
+<p> |
| 236 |
+Again rises the need to trust a higher-level component. When you trust the |
| 237 |
+kernel, you might be able to use the kernel key ring for this. |
| 238 |
+</p> |
| 239 |
+<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4. |
| 240 |
+ </span>Using private/public key cryptography</p> |
| 241 |
+<p class="secthead"><a name="doc_chap4_sect1">Validating integrity using public keys</a></p> |
| 242 |
+<p> |
| 243 |
+One way to work around the vulnerability of having the malicious user getting |
| 244 |
+hold of the secret key is to not rely on the key for the authentication of the |
| 245 |
+hash result in the first place when verifying the integrity of the system. This |
| 246 |
+can be accomplised if you, instead of using just an HMAC, you also encrypt HMAC |
| 247 |
+digest with a private key. |
| 248 |
+</p> |
| 249 |
+<p> |
| 250 |
+During validation of the hashes, you decrypt the HMAC with the public key (not |
| 251 |
+the private key) and use this to generate the HMAC digests again to validate. |
| 252 |
+</p> |
| 253 |
+<p> |
| 254 |
+In this approach, an attacker cannot forge a fake HMAC since forgery requires |
| 255 |
+access to the private key, and the private key is never used on the system to |
| 256 |
+validate signatures. And as long as no collisions occur, he also cannot reuse |
| 257 |
+the encrypted HMAC values (which you could consider to be a replay attack). |
| 258 |
+</p> |
| 259 |
+<p class="secthead"><a name="doc_chap4_sect2">Ensuring the key integrity</a></p> |
| 260 |
+<p> |
| 261 |
+Of course, this still requires that the public key is not modifyable by a |
| 262 |
+tampered system: a fake list of hash results can be made using a different |
| 263 |
+private key, and the moment the tool wants to decrypt the encrypted values, the |
| 264 |
+tampered system replaces the public key with its own public key, and the system |
| 265 |
+is again vulnerable. |
| 266 |
+</p> |
| 267 |
+<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5. |
| 268 |
+ </span>Trust chain</p> |
| 269 |
+<p class="secthead"><a name="doc_chap5_sect1">Handing over trust</a></p> |
| 270 |
+<p> |
| 271 |
+As you've noticed from the methods and services above, you always need to have |
| 272 |
+something you trust and that you can build on. If you trust nothing, you can't |
| 273 |
+validate anything since nothing can be trusted to return a valid response. And |
| 274 |
+to trust something means you also want to have confidence that that system |
| 275 |
+itself uses trusted resources. |
| 276 |
+</p> |
| 277 |
+<p> |
| 278 |
+For many users, the hardware level is something they trust. After all, as long |
| 279 |
+as no burglar has come in the house and tampered with the hardware itself, it is |
| 280 |
+reasonable to expect that the hardware is still the same. In effect, the users |
| 281 |
+trust that the physical protection of their house is sufficient for them. |
| 282 |
+</p> |
| 283 |
+<p> |
| 284 |
+For companies, the physical protection of the working environment is not |
| 285 |
+sufficient for ultimate trust. They want to make sure that the hardware is not |
| 286 |
+tampered with (or different hardware is suddenly used), specifically when that |
| 287 |
+company uses laptops instead of (less portable) workstations. |
| 288 |
+</p> |
| 289 |
+<p> |
| 290 |
+The more you don't trust, the more things you need to take care of in order to |
| 291 |
+be confident that the system is not tampered with. In the Gentoo Hardened |
| 292 |
+Integrity subproject we will use the following "order" of resources: |
| 293 |
+</p> |
| 294 |
+<ul> |
| 295 |
+ <li> |
| 296 |
+ <span class="emphasis">System root-owned files and root-running processes</span>. In most cases |
| 297 |
+ and most households, properly configured and protected systems will trust |
| 298 |
+ root-owned files and processes. Any request for integrity validation of |
| 299 |
+ the system is usually applied against user-provided files (no-one tampered |
| 300 |
+ with the user account or specific user files) and not against the system |
| 301 |
+ itself. |
| 302 |
+ </li> |
| 303 |
+ <li> |
| 304 |
+ <span class="emphasis">Operating system kernel</span> (in our case the Linux kernel). Although some |
| 305 |
+ precautions need to be taken, a properly configured and protected kernel can |
| 306 |
+ provide a higher trust level. Integrity validation on kernel level can offer |
| 307 |
+ a higher trust in the systems' integrity, although you must be aware that |
| 308 |
+ most kernels still reside on the system itself. |
| 309 |
+ </li> |
| 310 |
+ <li> |
| 311 |
+ <span class="emphasis">Live environments</span>. A bootable (preferably) read-only medium can be |
| 312 |
+ used to boot up a validation environment that scans and verifies the |
| 313 |
+ integrity of the system-under-investigation. In this case, even tampered |
| 314 |
+ kernel boot images can be detected, and by taking proper precautions when |
| 315 |
+ running the validation (such as ensuring no network access is enabled from |
| 316 |
+ the boot up until the final compliance check has occurred) you can make |
| 317 |
+ yourself confident of the state of the entire system. |
| 318 |
+ </li> |
| 319 |
+ <li> |
| 320 |
+ <span class="emphasis">Hypervisor level</span>. Hypervisors are by many organizations seen as |
| 321 |
+ trusted resources (the isolation of a virtual environment is hard to break |
| 322 |
+ out of). Integrity validation on the hypervisor level can therefor provide |
| 323 |
+ confidence, especially when "chaining trusts": the hypervisor first |
| 324 |
+ validates the kernel to boot, and then boots this (now trusted) kernel which |
| 325 |
+ loads up the rest of the system. |
| 326 |
+ </li> |
| 327 |
+ <li> |
| 328 |
+ <span class="emphasis">Hardware level</span>. Whereas hypervisors are still "just software", you |
| 329 |
+ can lift up trust up to the hardware level and use the hardware-offered |
| 330 |
+ integrity features to provide you with confidence that the system you are |
| 331 |
+ about to boot has not been tampered with. |
| 332 |
+ </li> |
| 333 |
+</ul> |
| 334 |
+<p> |
| 335 |
+In the Gentoo Hardened Integrity subproject, we aim to eventually support all |
| 336 |
+these levels (and perhaps more) to provide you as a user the tools and methods |
| 337 |
+you need to validate the integrity of your system, up to the point that you |
| 338 |
+trust. The less you trust, the more complex a trust chain might become to |
| 339 |
+validate (and manage), but we will not limit our research and support to a |
| 340 |
+single technology (or chain of technologies). |
| 341 |
+</p> |
| 342 |
+<p> |
| 343 |
+Chaining trust is an important aspect to keep things from becoming too complex |
| 344 |
+and unmanageable. It also allows users to just "drop in" at the level of trust |
| 345 |
+they feel is sufficient, rather than requiring technologies for higher levels. |
| 346 |
+</p> |
| 347 |
+<p> |
| 348 |
+For instance: |
| 349 |
+</p> |
| 350 |
+<ul> |
| 351 |
+ <li> |
| 352 |
+ A hardware component that you trust (like a <span class="emphasis">Trusted Platform Module</span> |
| 353 |
+ or a specific BIOS-supported functionality) verifies the integrity of the |
| 354 |
+ boot regions on your disk. When ok, it passes control over to the |
| 355 |
+ bootloader. |
| 356 |
+ </li> |
| 357 |
+ <li> |
| 358 |
+ The bootloader now validates the integrity of its configuration and of the |
| 359 |
+ files (kernel and initramfs) it is told to boot up. If it checks out, it |
| 360 |
+ boots the kernel and hands over control to this kernel. |
| 361 |
+ </li> |
| 362 |
+ <li> |
| 363 |
+ The kernel, together with the initial ram file system, verifies the |
| 364 |
+ integrity of the system components (and for instance SELinux policy) before |
| 365 |
+ the initial ram system changes to the real system and boots up the |
| 366 |
+ (verified) init system. |
| 367 |
+ </li> |
| 368 |
+ <li> |
| 369 |
+ The (root-running) init system validates the integrity of the services it |
| 370 |
+ wants to start before handing over control of the system to the user. |
| 371 |
+ </li> |
| 372 |
+</ul> |
| 373 |
+<p> |
| 374 |
+An even longer chain can be seen with hypervisors: |
| 375 |
+</p> |
| 376 |
+<ul> |
| 377 |
+ <li> |
| 378 |
+ Hardware validates boot loader |
| 379 |
+ </li> |
| 380 |
+ <li> |
| 381 |
+ Boot loader validates hypervisor kernel and system |
| 382 |
+ </li> |
| 383 |
+ <li> |
| 384 |
+ Hypervisor validates kernel(s) of the images (or the entire images) |
| 385 |
+ </li> |
| 386 |
+ <li> |
| 387 |
+ Hypervisor-managed virtual environment starts the image |
| 388 |
+ </li> |
| 389 |
+ <li> |
| 390 |
+ ... |
| 391 |
+ </li> |
| 392 |
+</ul> |
| 393 |
+<p class="secthead"><a name="doc_chap5_sect2">Integrity on serviced platforms</a></p> |
| 394 |
+<p> |
| 395 |
+Sometimes you cannot trust higher positioned components, but still want to be |
| 396 |
+assured that your service is not tampered with. An example would be when you are |
| 397 |
+hosting a system in a remote, non-accessible data center or when you manage an |
| 398 |
+image hosted by a virtualized hosting provider (I don't want to say "cloud" |
| 399 |
+here, but it fits). |
| 400 |
+</p> |
| 401 |
+<p> |
| 402 |
+In these cases, you want a level of assurance that your own image has not been |
| 403 |
+tampered with while being offline (you can imagine manipulating the guest image, |
| 404 |
+injecting trojans or other backdoors, and then booting the image) or even while |
| 405 |
+running the system. Instead of trusting the higher components, you try to deal |
| 406 |
+with a level of distrust that you want to manage. |
| 407 |
+</p> |
| 408 |
+<p> |
| 409 |
+Providing you with some confidence at this level too is our goal within the |
| 410 |
+Gentoo Hardened Integrity subproject. |
| 411 |
+</p> |
| 412 |
+<p class="secthead"><a name="doc_chap5_sect3">From measurement to protection</a></p> |
| 413 |
+<p> |
| 414 |
+When dealing with integrity (and trust chains), the idea behind the top-down |
| 415 |
+trust chain is that higher level components first measure the integrity of the |
| 416 |
+next component, validate (and take appropriate action) and then hand over |
| 417 |
+control to this component. This is what we call <span class="emphasis">protection</span> or |
| 418 |
+<span class="emphasis">integrity enforcement</span> of resources. |
| 419 |
+</p> |
| 420 |
+<p> |
| 421 |
+If the system cannot validate the integrity, or the system is too volatile to |
| 422 |
+enforce this integrity from a higher level, it is necessary to provide a trusted |
| 423 |
+method for other services to validate the integrity. In this case, the system |
| 424 |
+<span class="emphasis">attests</span> the state of the underlying component(s) towards a third party |
| 425 |
+service, which <span class="emphasis">appraises</span> this state against a known "good" value. |
| 426 |
+</p> |
| 427 |
+<p> |
| 428 |
+In the case of our HMAC-based checks, there is no enforcement of integrity of |
| 429 |
+the files, but the tool itself attests the state of the resources by generating |
| 430 |
+new HMAC digests and validating (appraising) it against the list of HMAC digests |
| 431 |
+it took before. |
| 432 |
+</p> |
| 433 |
+<p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6. |
| 434 |
+ </span>An implementation: the Trusted Computing Group functionality</p> |
| 435 |
+<p class="secthead"><a name="doc_chap6_sect1">Trusted Platform Module</a></p> |
| 436 |
+<br><p class="copyright"> |
| 437 |
+ The contents of this document, unless otherwise expressly stated, are |
| 438 |
+ licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0">CC-BY-SA-3.0</a> license. The <a href="http://www.gentoo.org/main/en/name-logo.xml"> Gentoo Name and Logo Usage Guidelines </a> apply. |
| 439 |
+ </p> |
| 440 |
+<!-- |
| 441 |
+ <rdf:RDF xmlns="http://web.resource.org/cc/" |
| 442 |
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> |
| 443 |
+ |
| 444 |
+ <License rdf:about="http://creativecommons.org/licenses/by-sa/3.0/"> |
| 445 |
+ |
| 446 |
+ <permits rdf:resource="http://web.resource.org/cc/Reproduction" /> |
| 447 |
+ <permits rdf:resource="http://web.resource.org/cc/Distribution" /> |
| 448 |
+ <requires rdf:resource="http://web.resource.org/cc/Notice" /> |
| 449 |
+ <requires rdf:resource="http://web.resource.org/cc/Attribution" /> |
| 450 |
+ <permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" /> |
| 451 |
+ <requires rdf:resource="http://web.resource.org/cc/ShareAlike" /> |
| 452 |
+ </License> |
| 453 |
+ </rdf:RDF> |
| 454 |
+--><br> |
| 455 |
+</td> |
| 456 |
+<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px"> |
| 457 |
+<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="swift?style=printable">Print</a></p></td></tr> |
| 458 |
+<tr><td class="topsep" align="center"><p class="alttext">Page updated July 30, 2012</p></td></tr> |
| 459 |
+<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b> |
| 460 |
+Integrity validation is a wide field in which many technologies play a role. |
| 461 |
+This guide aims to offer a high-level view on what integrity validation is all |
| 462 |
+about and how the various technologies work together to achieve a (hopefully) |
| 463 |
+more secure environment to work in. |
| 464 |
+</p></td></tr> |
| 465 |
+<tr><td align="left" class="topsep"><p class="alttext"> |
| 466 |
+ <a href="mailto:swift@g.o" class="altlink"><b>Sven Vermeulen</b></a> |
| 467 |
+<br><i>Author</i><br></p></td></tr> |
| 468 |
+<tr lang="en"><td align="center" class="topsep"> |
| 469 |
+<p class="alttext"><b>Donate</b> to support our development efforts. |
| 470 |
+ </p> |
| 471 |
+<form action="https://www.paypal.com/cgi-bin/webscr" method="post"> |
| 472 |
+<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@g.o"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo"> |
| 473 |
+</form> |
| 474 |
+</td></tr> |
| 475 |
+<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr> |
| 476 |
+</table></td> |
| 477 |
+</tr></table></td></tr> |
| 478 |
+<tr><td colspan="2" align="right" class="infohead"> |
| 479 |
+Copyright 2001-2012 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>. |
| 480 |
+</td></tr> |
| 481 |
+</table></body> |
| 482 |
+</html> |
Archives
![http://www.gentoo.org/images/paypal.png"><input](http://www.gentoo.org/images/paypal.png"><input){kind=link}
