Re: TPM disk crypto
cyphrpunk wrote: 1. The issue is still moot at present. We are a long way from where open, public, remote attestion will be possible. See this diagram from the Trousers open-source TPM software stack project which shows which pieces are still missing: http://trousers.sourceforge.net/remote_attestation_deps.png so i did do fab process and associated infrastructure for tpm-like chips that recorded public key at manufacturing time. this came up in recent thread on trusting chips and/or knowing integrity level of chips http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Travis H. wrote: I can validate everything else, but as long as the BIOS is motherboard-specific and closed source, I don't see why I should trust it. We need to get rid of this legacy crud. LinuxBIOS is a good step but unfortunately it is only supported on a few motherboards. We're shipping LinuxBIOS on the One Laptop per Child machines. No BIOS I know of has a semblance of security, given temporary physical access to the machine. I came up with a scheme that lets us do a secure BIOS without a TPM; bypassing it without a PLCC would be extremely difficult. I'm not yet certain if we'll end up shipping a PLCC socket on the final hardware, but if not, I suspect you'd be hard-pressed to do much to the BIOS protection even with physical access, short of un-soldering and re-soldering a different SPI flash chip to the motherboard. That was explicitly not part of my threat model. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Alexander Klimov wrote: Since a regular installation should not change ``reported OS hash,'' TPM will not be able to detect the difference. Am I missing something? You're missing the marketing value of saying this piece of hardware, that you probably wouldn't otherwise want in your machine since it makes sure that the machine can be trusted /against/ you, is great! Because it protects you against trojans! And everyone wants to be safe from trojans, right?. Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? The Microsoft guy presenting BitLocker at HITB last month mentioned this, but glossed over it without explaining. He did seem to indicate that they had some solution, but didn't provide details, IIRC. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Kuehn, Ulrich wrote: Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. What does prove mean here? Does having a hash of the system state for visual inspection before boot do it? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Passwords jump-started Fumo probe
http://www.philly.com/mld/inquirer/news/local/states/pennsylvania/counties/philadelphia_county/philadelphia/15727557.htm The feds were unable to break the encrypted email files until one admin came up with a password list on a portable drive. I wonder if they tried to brute-force the password? nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication https://www.linkedin.com/in/nickowen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
| Given how rare weak keys are in modern ciphers, I assert that code to cope | with them occurring by chance will never be adequately tested, and will be | more likely to have security bugs. In short, why bother? Beyond that: Are weak keys even detectable using a ciphertext-only attack (beyond simply trying them - but that can be done with *any* small set of keys)? If not, what's the attack? One could posit an attack in which some of the plaintext is known, and an attacker could detect the weak key from known ciphertext/plaintext pairs and then use the detected key to attack the rest of the ciphertext. But that's an odd attack to defend against - why not just try all the weak keys (or, again, any small subset of keys) and see if they work? The only kind of weak key that would matter is one that leaves the ciphertext mainly or entirely unchanged - e.g., leaves most of the bits unchanged or most of them always flipped. This suggests that, rather than looking for weak keys as such, it might be worth it to do continuous online testing: Compute the entropy of the generated ciphertext, and its correlation with the plaintext, and sound an alarm if what you're getting looks wrong. This might be a worthwhile thing to have, not just for detecting weak keys, but to detect all kinds of software and hardware failures. Since it's outside of the actual encryption datapath, a bug either fails to sound an alarm when it should - leaving you where you were without this new check - or sounds a false alarm, which unless it occurs too often, shouldn't be such a big deal. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
On Thu, 12 Oct 2006 16:50:13 -0400 (EDT), Leichter, Jerry [EMAIL PROTECTED] wrote: This suggests that, rather than looking for weak keys as such, it might be worth it to do continuous online testing: Compute the entropy of the generated ciphertext, and its correlation with the plaintext, and sound an alarm if what you're getting looks wrong. This might be a worthwhile thing to have, not just for detecting weak keys, but to detect all kinds of software and hardware failures. Since it's outside of the actual encryption datapath, a bug either fails to sound an alarm when it should - leaving you where you were without this new check - or sounds a false alarm, which unless it occurs too often, shouldn't be such a big deal. This is a very interesting suggestion, but I suspect people need to be cautious about false positives. MP3 and JPG files will, I think, have similar entropy statistics to encrypted files; so will many compressed files. For a more substantive, less hand-wavey analysis, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf which has actual file system entropy measurements. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
| This suggests that, | rather than looking for weak keys as such, it might be worth it to | do continuous online testing: Compute the entropy of the generated | ciphertext, and its correlation with the plaintext, and sound an | alarm if what you're getting looks wrong. This might be a | worthwhile thing to have, not just for detecting weak keys, but | to detect all kinds of software and hardware failures. Since it's | outside of the actual encryption datapath, a bug either fails to | sound an alarm when it should - leaving you where you were without | this new check - or sounds a false alarm, which unless it occurs | too often, shouldn't be such a big deal. | | This is a very interesting suggestion, but I suspect people need to be | cautious about false positives. MP3 and JPG files will, I think, have | similar entropy statistics to encrypted files; so will many compressed | files. I'm not sure which direction you want false positive to refer to. If the input is already random-looking, then any encryption of it, good or bad (other than very silly ones which grossly expand the input) will also be random-looking. So you'll never trip the output doesn't look random enough detector. On the other hand, some simple correlation analysis between input and output *might* detect some simple failures. (You could also look for the non-random pieces, like the headers on JPG's. Not sure it's really worth it - about the only time you're going to find that is when the output and the input are essentially identical.) -- Jerry | For a more substantive, less hand-wavey analysis, see | http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf | which has actual file system entropy measurements. | | | --Steven M. Bellovin, http://www.cs.columbia.edu/~smb | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/10/06, Adam Back [EMAIL PROTECTED] wrote: I think the current CPUs / memory managers do not have the ring -1 / curtained memory features, but already a year ago or more Intel and AMD were talking about these features. So its possible the for example hypervisor extra virtualization functionality in recent processors ties with those features, and is already delivered? Anyone know? Intel LaGrande Technology is supposed to ship soon and combines virtualization with TPM integration so you can load what they call a MVMM: a measured virtual machine monitor. Measured means the hash goes securely to the TPM so it can attest to it, and third parties can verify what VMM you are running. Then the security properties would depend on what the VMM enforces. The MVMM runs in what you might call ring -1, while the OS running in ring 0 has only virtualized access to certain system resources like page tables. One thing the MVMM could do is to measure and attest to OS properties. Then if you patched the OS to bypass a signed-driver check, it might not work right. One question that was raised is how these systems can be robust against OS upgrades and such. It would seem that ultimately this will require attestation to be based on a signing key rather than the code fingerprint. Rather than hashing the code it loads, the MVMM would verify that the code is signed by a certain key, and hash the key, sending that to the TPM. Then any code signed by the same key could produce the same attestation and have access to the same sealed data. The TCG infrastructure working group is supposed to standardize what kinds of attestions will be used and what they will mean. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
James A. Donald: Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. Alexander Klimov wrote: The argument that TPM can prevent trojans seems to imply that the trojans are installed by modification of raw storage while the OS is offline. No it does not. Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? It can report that the hash is a value that has been blessed by signed software - and can report that its list of reputable signing authorities is blessed by Microsoft, and does not include me. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
On 10/12/06, Leichter, Jerry [EMAIL PROTECTED] wrote: Beyond that: Are weak keys even detectable using a ciphertext-only attack (beyond simply trying them - but that can be done with *any* small set of keys)? Yes, generally, that's the definition of a weak key. But that's an odd attack to defend against - why not just try all the weak keys (or, again, any small subset of keys) and see if they work? Because that's the definition of brute forcing, and generally the key distribution is close to uniform in any [symmetric] system that is worth a second glance? do continuous online testing: Compute the entropy of the generated ciphertext, and its correlation with the plaintext, and sound an alarm if what you're getting looks wrong. This is a decent idea. Of course, there are scads of problems that are not detectable by a simple memoryless markov model, but this would be a decent sanity check on all but the smallest of plaintexts. I would also want continuous monitoring of my HWRNG outputs; maybe I wouldn't want a simple entropy check, which a properly-functioning HWRNG will fail with a probability predicted by chance, but perhaps a graphical display of the previous values. I'm not a visual thinker, but I don't think any amount of statistics are going to be as useful in detecting deviations from uniformity as a plot and a human brain. -- The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -- URL:http://www.subspacefield.org/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Here is a posting from the cypherpunks mailing list describing the capabilities of Intel's new virtualization/TPM technology. Gets a bit ranty but still good information. CP -- Forwarded message -- From: Anonymous Remailer (austria) [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 03:25:57 +0200 (CEST) Subject: Palladium is back. And this time, it's... To: [EMAIL PROTECTED] In the past few weeks new information has come out on the Trusted Computing (TC) front which provides clues to where this powerful and controversial technology may be heading. Much of this has come from Intel, which has revealed more information about their LaGrande technology, now un-codenamed to Trusted Execution Technology. A good source of links is the Hack the Planet blog, http://wmf.editthispage.com/ - scroll down to the September 25 entry. LaGrande was originally designed as the hardware support for Microsoft's now-defunct Palladium, relating to the differences between Palladium and TCPA (now called TCG). Both technologies relied on the TPM chip to take measurements of running software, report those measurements remotely via trusted attestations, and lock encrypted data to those measurements so that other software configurations could not decrypt it. These are the core capabilities which give TC its power. But there were important differences in the two approaches. TCPA was focused on a measured boot process. As the system boots, each stage would measure (i.e. hash into the TPM) the next stage before switching control to it. At the end of this process the TPM's Platform Configuration Registers would hold a fingerprint of the software configuration that had booted. With a TPM-aware OS the PCRs could be further updated as each program launches to keep an up-to-date picture of what is running. Palladium instead wanted to be able to switch to trusted mode in mid stream, after booting; and wanted to continue to run the legacy OS while new applications ran in the trusted area. LaGrande Technology (LT, now TET), in conjunction with new TPM capabilities offered in the 1.2 chips now available, would provide the support for this late launch concept. Palladium is now gone but Intel has continued to develop LaGrande and has now released documentation on how it will work, at http://www.intel.com/technology/security/. Late launch starts with the OS or the BIOS executing one of the new LT instructions. This triggers a complex sequence of operations whose purpose is to load, measure (ie hash into the TPM) and launch a hypervisor, that is, a Virtual Machine Monitor (VMM). The hypervisor can then repackage the state of the launching OS as a Virtual Machine (VM) and transfer control back to it. The OS has now become transparently virtualized and is running on top of the VMM. The VMM can then launch secure VMs which execute without being molested by the legacy OS. Another enhancement of LT is that the chipset can be programmed to prevent DMA access to specified memory areas. This will close a loophole in existing VMM systems, that VMs can program DMA devices to overwrite other VMs' memory. This protection is necessary for the TC goal of protected execution environments. Both VMWare and Xen are getting involved with this technology. As the blog entry above says, Intel donated code to Xen a few days ago to support much of this functionality, so that Xen will be able to launch in this way on TET machines. Another link from the blog entry is an amazing Intel presentation showing how excited the NSA is about this technology. Within a couple of years they will be able to acquire Commercial Off the Shelf (COTS) systems configured like this, that will allow running multiple instances of OS's with different security classifications. The slides show a system running two versions of Windows, one for Secret and one for Top Secret data, appearing in separate windows on the screen. Xen or VMWare with TET will be able to do this very soon if not already. Here's Intel's description of how software might be configured to use this capability, from their Trusted Execution Technology Architectural Overview linked from the LaGrande page above: Trusted Execution Technology provides a set of capabilities that can be utilized in many different operating environments (Figure 2). One proposed architecture provides a protection model similar to the following: A standard partition that provides an execution environment that is identical to today's IA-32 environment. In this environment, users will be able to run applications and other software just as they do on today's PC. The standard partition's obvious advantage is that it preserves the value of the existing code base (i.e. existing software does not need modification to run in the standard partition) and potential future software that is less security conscious. Unfortunately, it also retains the inherent vulnerabilities of today's environment. A protected partition provides a
RE: OpenSSL PKCS #7 supports AES SHA-2 ?
Read RFC4055 for RSA with various hashes, OAEP, and PSS combinations. - Tolga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Alten Sent: Tuesday, October 10, 2006 9:47 AM To: Russ Housley; cryptography@metzdowd.com Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL PKCS #7 supports AES SHA-2 ? Russ, OK. I found SHA-2 in RFC 4634 (only 3 months old), which refers back to FIPS 180-2. But I reach a dead-end with PKCS #7 (now RFC 3852). There's no support for SHA-2 algorithm types (RFC 3279). Also PKCS #1 (now RFC 3447) needs an update for SHA-2 with RSA encryption (OIDs, etc.). Did I miss something or do you need help in updating these, since I, and probably others too, need them? - Alex At 01:19 PM 10/9/2006 -0400, Russ Housley wrote: PKCS#7 has been turned over to the IETF for maintenance. The most recent version is RFC 3852. Since the protocol is more stable than the cryptographic algorithms, the algorithm discussion appear in separate RFCs. TLS 1.2 is under development in the IETF. It is being done in such a way that none of the ciphersuites that have already been defined need to be updated, including the ones that use AES and the SHA-2 family. Russ At 01:28 AM 10/7/2006, Alex Alten wrote: After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs, therefore OpenSSL PKCS #7 functions won't support SHA-2. This spec was last updated in 1998. PKCS Editor, is there a new update in progress by RSA Labs to incorporate SHA-2 and AES? Does OpenSSL implement PKCS #1 v2 or just v1.5? If the latter then not even SHA-1 is supported. PKCS editor, is there any timeline as to when PKCS #7 will then be updated with references to official OIDs, etc., for specifying SHA-2 and AES? Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for SHA-1 and SHA-2? (So that they can be referenced by an updated PKCS #7.) Mr. Russ Housley, can you weigh in with what happening in the IETF WG security area? I know that Mr. Eric Rescorla is working on a new TLS v1.2 draft. Will this be done/ratified soon? I assume OpenSSL will incorporate this soon thereafter? This mess with the MD5 and SHA-1 hashes is really starting to becoming a problem. It's certainly impacting new development projects/products I'm involved with using SSL and PKI certificates. My customers are concerned about using MD5 and SHA-1, and they don't want to keep paying for implementations repeatedly as the standards catch up to reality. Updating these various heavily used standards quickly is quite important. Sincerely (and thanks in advance for all of your replies), - Alex At 09:05 AM 10/6/2006 -0700, Alex Alten wrote: Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2? (I assuming OpenSSL 0.9.7 or later.) Thanks, - Alex -- Alex Alten Alten Security Engineering, Inc. [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Dienstag 10 Oktober 2006 01:35 schrieb Travis H.: What is the accepted way to derive several keys from a user-supplied input? Maybe RFC289. AFAIK it also describes the reason why it protects against dictionary attacks. Bye, Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.: On 10/13/06, Thomas [EMAIL PROTECTED] wrote: Maybe RFC289. I assume you mean 2289, which appears to describe the OTP scheme used by S/key. sorry, it was too early for an copy-n-paste ;) i meant: B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0; RFC289 Bye, Thomas -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
Travis H. [EMAIL PROTECTED] writes: On 10/12/06, Leichter, Jerry [EMAIL PROTECTED] wrote: Beyond that: Are weak keys even detectable using a ciphertext-only attack (beyond simply trying them - but that can be done with *any* small set of keys)? Yes, generally, that's the definition of a weak key. No, that is not the definition of a weak key. Look at DES weak keys, for example. They are simply keys for which the encryption and decryption transform are identical -- encrypting twice with the weak key returns you to the plaintext -- but they are not in some way obviously detectable without trying them. Might I suggest reading the literature on this before discussing it further? Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: deriving multiple keys from one passphrase
Am Freitag 13 Oktober 2006 12:26 schrieb Thomas: Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.: On 10/13/06, Thomas [EMAIL PROTECTED] wrote: Maybe RFC289. I assume you mean 2289, which appears to describe the OTP scheme used by S/key. sorry, it was too early for an copy-n-paste ;) i meant: B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0; RFC289 hm, the last 8 is missing again. rfc2898 t. -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: TPM disk crypto
From: Ivan Krstić [mailto:[EMAIL PROTECTED] Kuehn, Ulrich wrote: Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. What does prove mean here? Does having a hash of the system state for visual inspection before boot do it? Well, reliably obtaining the end of a hash chain would do, but it would be very inconvenient to compare that manually (visually) to a hash written on a piece of paper in my wallet. That is not user-friendly. However, if the system provided a possibility to reliably stop the boot process when something is changed, that would do. With reliably stopping the boot process I mean the following: Given that stage i of the process is running, it takes the hash of the next stage, compares that to an expected value. If they match, the current stage extends the TPM register (when also running the TCG stuff), and executes the next stage. If the computed and expected hashes do not match, the machine goes into a predetermined halt state. Predetermined means that the system administrator (on behalf of the system owner) can determine the expected hash value. I hope this makes it clear what I meant in the text quoted above. To implement this the TCG-preBIOS would need to implement this halt state, possibly along with some other additional features like where to store the expected hashes etc. Cheers, Ulrich - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/13/06, Kuehn, Ulrich [EMAIL PROTECTED] wrote: With reliably stopping the boot process I mean the following: Given that stage i of the process is running, it takes the hash of the next stage, compares that to an expected value. If they match, the current stage extends the TPM register (when also running the TCG stuff), and executes the next stage. If the computed and expected hashes do not match, the machine goes into a predetermined halt state. Predetermined means that the system administrator (on behalf of the system owner) can determine the expected hash value. You don't need the TPM for this. You could imagine a boot process where each stage hashed the next stage, and refused to proceed if it didn't match an expected value. One question though is how you prevent malware from changing these expected values, even potentially reflashing the BIOS. A student project at Dartmouth a few years ago, enforcer.sourceforge.net, worked like this. It could also optionally use a TPM but didn't have to. The project appears to be abandoned but the supervising professor, Sean Smith, in his book Trusted Computing Platforms says that new students are bringing it up to date, getting it working with newer kernels including selinux support. Here's the Enforcer description. Nice piece of work. Hopefully they'll release an updated version now that TPMs are more common. The Enforcer is a Linux Security Module designed to improve integrity of a computer running Linux by ensuring no tampering of the file system. It can interact with TCPA hardware to provide higher levels of assurance for software and sensitive data. It can check, as every file is opened, if the file has been changed, and take an admin specified action when it detects tampering. The actions can be any combination of log the error, deny access to the file, panic the system, or several operations that work with the TPM. The Enforcer can also work with the TPM to store the secret to an encrypted loopback file system, and unmount this file system when a tampered file is detected. The secret will not be accessible to mount the loopback file system until the machine has been rebooted with untampered files. This allows sensitive data to be protected from an attacker. The Enforcer can also bind specific files so that only specific applications can access them (for example, only apache is allowed to access apache's secret ssl key). This means that even if someone compromises your system, the attacker will not be able to steal critical files. Finally, the Enforcer can make sure that no files added to directories after its database is built are allowed to be accessed. One thing they worked hard on in the design is the balance between detecting malicious changes, and allowing necessary changes for maintenance and upgrades. They identified different classes of components that were updated seldom, occasionally or frequently, and architected the system to provide an appropriate degree of checking for each category. The academic paper is here: http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
At 17:05 -0400 2006/10/12, Steven M. Bellovin wrote: This is a very interesting suggestion, but I suspect people need to be cautious about false positives. MP3 and JPG files will, I think, have similar entropy statistics to encrypted files; so will many compressed files. Actually, no. I have a general purpose stats program that I often use for cryptanalysis as part of my tookit. I pointed it at my photos folder, and every single jpeg file had results like this: samples: 88246 unique: 256 sum: 11413854 sum squares: 1943201034 maximum: 255 minimum: 0 range:255 mean: 129.34132 variance: 5291.1565 std dev: 72.740336 median: 130 exp freq: 344.71094 max freq: 623 mode count: 1 mode: 0 min freq: 109 unmode count: 1 unmode: 192 chi^2:4375.0414 chi^2 df: 255 pr(chi^2):1.0 (*** certainly non-uniform distribution ***) bad buckets: 96 KS+: 1.0002392 pr(KS+): 0.86510 KS-: 6.6097712 pr(KS-): 1.0 (*** certainly non-uniform distribution ***) KS(both): 3.8050052 pr(KS_BOTH): 1.0 The simplest test is just the chi-squared test on the frequency of bytes, and it's way out of range on even fairly small jpegs. The Kolmogorov-Smirnoff test almost always bingos too. And even if the chi-squared passes, the binomial test on individual byte-value frequencies will flag the data as non-random; note the bad buckets count above; the detailed output is suppressed when the chi-squared test fails, since there will generally be too much of it. The only things that it usually passes as good are for-purpose random number generators' or ciphers' outputs. Everything else (including a terabyte of RC4 output, executables, zip archives, jpegs, mpegs, mp3s, ...) that I've pointed it at, fails one or more of the tests. True random-looking-ness is hard to find... :-) Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
