Re: [Linux-ima-user] Doubt related to Secure Boot process

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Reiner,

Thanks a lot for your inputs.. :)

Thanks & Regards,
-Bhanu.

On 7/20/07, Reiner Sailer <sa...@us...> wrote:
>
> 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
>
>