From: Reiner S. <sa...@us...> - 2007-07-20 02:13:18
|
Hello Bhanu, lin...@li... wrote on 07/19/2007 01:26:50 AM: > > Hi Reiner, > > Thanks for your response.. > > Now I am better in understanding of these concepts.. but still have > some doubts.. :_) > 1. The process that you have mentioned/incorporated in IMA is one of > the possible approach or is it a standard one? IMA is one approach. It seems a natural extension of the boot-process measurements that TCG has standardized. There is ongoing work in the TCG on the management of integrity measurements. Unfortunately, I am not able (time-wise :-) to follow the TCG work closely. You might find more in the TCG infrastructure working group that is focused on interoperability of TC technology in the enterprise. https://www.trustedcomputinggroup.org/groups/infrastructure/ Once standards are agreed upon, IMA will certainly aim at supporting those formats. > 2. Is it possible for the verifier to identify every program (All applications > ) by a hash value ? i.e. whether challenger will do any checks on > any unauthorized program is running on the machine ?? Different programs have different SHA1 values (until SHA1 is broken). Since we measure a program before it is relocated, every program will yield exactly one predictable measurement independently where in memory it is located (not true for configuration files that can change between measurement .... there is still research work waiting to happen). -->challengers can check if a specific program was started since reboot The challenger must know to which of the endless number of possible programs a hash value relates. This is where hash data bases come in as value. IMA does not say, however, if the program is still running. I am thinking about integrating such a feature to IMA if I or others find a simple way. > 3. When referring to TCG Specification Architecture Overview - It > was mentioned that "The SML can become very large. Therefore it does > not reside in the TPM. The SML does not need the protection afforded > by the TPM as attacks against the SML would be detected. However, > SML is still subject to denial of service attacks. Implementers > should take steps to replicate or regenerate the log." - I am a bit > confused on how to replicate or regenerate the log also whether TPM > will store any digest value of SML to check the integrity of the > measurement log?? This could relate to the fact that by creating sufficient measurements, an attacker could exhaust the memory of the system that stores the measurements (sound a little theoretical because even IMA has a cap and does record only a max number of measurements). To avoid running into such a cap, one could imagine to off-load the measurements from the system. In any case, the TPM will store the integrity aggregate over all 'extended' measurements between boot-cycles. So wherever the measurement list resides, it can be verified with the TPM PCR quote from the measuring system. > Thanks & Regards, > -Bhanu. > Greetings Reiner > On 7/15/07, Reiner Sailer < sa...@us...> wrote: > Hi Bhanu, > > these are very good questions. I answer them inline as good as I can. > However, there are opportunities for interesting work :-) > > Bhanu < bha...@gm... > wrote on 07/13/2007 02:06:52 AM: > > > Hi Reiner, > > > > Thanks for your response. > > > > While booting any measurement [for Boot Loader, IPL code, Kernel > > etc.. ] is verified w.r.to any standard values? As, I didn't find > > anything like verification in the spec. It just says Measurement, > > Storage and Reporting. > > > > Is there any relation with validation credentials in this process?? > > IMA is non-intrusive, i.e., it does not restrict the system in any way > other than ensuring that measurements are taken and protected. > Any validation happens at the verifier that requests a quote and the > measurements from remote. > > > According to my understanding, tpm will not verify any of the > > measurement calculated at the time of start up with any value. Is > > that mean if any malfunctioning happens to the kernel code it will > > not be detected at the time of booting by the client? > > Yes. Also IMA does nothing to protect the client (non-intrusive means both > to good and bad). However, such functionality could be easily added as > described in our 2004 IMA paper: IMA could preload the measurement cache > and only load files whose measurements are in the cache. This, however, is > not the approach we implemented for the open source. > > > And one more thing is, At the time of attestation TPM will provide > > a signed PCR values along with the Measurement Log to the challeneger. > > > > From the link, http://domino.research.ibm.com/comm/research_people . > > nsf/pages/sailer.ima.html > > > > Verifying the PCR aggregate > > > > in PCR: TPM-signed aggregate from step 3 > > in MList: Measurement list from step 3 > > > > { > > uchar PCR_tmp[20] = {0...0} > > > > for (i=0; i<MList.len; i++) > > PCR_tmp = SHA1(PCR_tmp|MList[i]) > > > > if (PCR == PCR_tmp) > > return OK > > else > > return INVALID > > } > > > > Spec. doesn't say anything about Tpm will extend all the > > measurements to one PCR. > > The IMA-enabled kernel decides where run-time measurements go. The PCR IMA > uses is actually a kernel config option. IMA could also encode the used > PCR into the first measurement and the verifier could get it from the > measurement list. The measurements can include the PCR number and this way > verification would be similar to the way described above. IMA could use > multiple PCRs in which case the verification procedure would apply to all > of those. > > > > > If the extend operation performed to different PCR values. How would > > the challenger will identify - which PCR to quote ?? > > The measurement of the kernel will show a different SHA value if it uses > different PCRs since the target PCR number is compiled into the kernel. > The verifier can infer the PCR value from this measurement of the kernel, > which can be found in PCR 0-7 and is part of the bios measurement log. > > > My main problem is, the measurements that were calculated at booting > > time [0-7] are not verified at Challenger side also. If it so, then > > it will greatly impact the Basic Concept of Core Root of Trust > mechanism. > > In general, the early boot process (before the OS is running) extends into > multiple PCRs. There is a PC specification for TPM, which describes where > which measurements are supposed to go. Using dynamic root of trust of TPM > 1.2 seems a more efficient way of providing initial good state > information. See for example OSLO ( > http://os.inf.tu-dresden.de/~kauer/oslo/). > > IMA currently uses a so-called 'boot-aggregate', which aggregates PCR 0-7 > into the very first IMA measurement when the kernel starts. As long as > this aggregate does not change, it is easy to re-verify a known boot > process. The verifier MUST always check that the boot-aggregate actually > is the aggregate of PCRs 0-7. This connects the boot process measurements > with IMA. > > --> IMA currently verifies the boot process as part of verifying the > validity of the very first measurement (boot-aggregate). > > > [From step 6 of attestation process from the above link, it says he > > challenging party starts identifying the source for each measurement > > in the measurement list and determines if this source (specific data > > file or executable) is trusted not to manipulate future measurements... > > > > Our data bases for Redhat Fedora Core 3 or 4 include around 25000 > > measurements, typical measurement lists accumulate about 700-1000 > > measurement... ] > > > > In this process, the challenger has to maintain this list for each > > operating system, each version and for patches... it will become > > very huge.. is there any work around for this?? > > There is no shortcut. If we identify every program by a hash value, then > we will see different hash values for different programs. We need to know > them to verify them. The good part: it is not as bad as one would expect > and it can be automated; I automated the process of keeping a pre-computed > measurement DB. Using this DB, I correctly verified multiple Fedora Core > systems without getting unknown measurements (as long as these systems run > only FC programs etc.). As of today, my precomputed db for Fedora Core > 4,5,6 including os, extras, and updates comprises less than 150.000 > measurements for each release (RHEL 3/4 ws/as/es yield considerably > smaller DB sized). Managing those DBs and phasing out measurements of old > programs etc. will keep them pretty manageable. > > The hardest problem pose files that change from system to system but are > important (httpd.conf, ssh.conf, resolv.conf, certificate files) etc. > Verifying files that change in a scalable way for thousands of systems is > still a challenge. > > > Pls. throw some light on this.. > > Hope this helps. > > > Thanks & Regards, > > -Bhanu. > > Reiner > > > On 7/12/07, Reiner Sailer < sa...@us...> wrote: > > Hi Bhanu, > > > > at startup time all IMA information is cleared. PCRs are reset by any > TPM > > and the IMA kernel does not keep any persistent information with regard > to > > the measurements. > > > > Reiner > > __________________________________________________________ > > Reiner Sailer, Research Staff Member, Secure Systems Department > > IBM T J Watson Research Ctr, 19 Skyline Drive, Hawthorne NY 10532 > > Phone: 914 784 6280 (t/l 863) Fax: 914 784 6205, sa...@us... > > http://www.research.ibm.com/people/s/sailer/ > > > > > > > > Bhanu <bha...@gm...> > > Sent by: lin...@li... > > 07/12/2007 07:17 AM > > > > To > > lin...@li... > > cc > > > > Subject > > [Linux-ima-user] Doubt related to Secure Boot process > > > > > > > > > > > > > > Hi, > > > > At the time of PC shut down where are the PCR values get stored (Is it > > required at all??), as a reference for comparison on next boot since > > volatile memory is bound to be reset on shutdown.I assume DIR [Hash of > all > > static PCR values(0-15 as per PC client Specification)] used to be the > > storage place in 1.1 TPM but what is the case in 1.2 TPM. > > > > Thanks & Regards, > > Bhanu. > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Linux-ima-user mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user |