Hi Andreas, thank you very much for your explanation. Maybe let me try to explain again what I meant.
My thought was that maybe it would be enough if device 'A' would measure only GRUB/bootchain + kernel + IMA database + strongswan attestation software, and then send the combined hash over to device 'B'. That could lead to a quite stable hash per device. Changes to the database or attestation software should be logged by the TPM in the same way as the TPM is measuring all executions in the current remote attestation system. I thought that so far device 'B' already had to trust the implementation of GRUB/bootchain + kernel + strongswan attestation software on device 'A' in order for an attested hash to be meaningful. So all that the trusted code base would have to be extended for would be the IMA database and especially the software that checks the IMA log against the database. To put it into a bigger picture, let me compare it with the following remote attestation concepts, I hope I got them right ;). 1: appraisal system bootchain + kernel + strongswan + appraisal root value have to be attested advantages: - small and stable attestation - details of what was actually loaded or mapped are be hidden disadvantage: - the attesting system is rather locked down 2: current remote attestation system bootchain + kernel + strongswan + full IMA log have to be attested advantages: - the attesting system is not locked down disadvantage: - large and unstable attestation - details of what was actually loaded or mapped can not be hidden 3: proposed remote attestation system bootchain + kernel + strongswan + IMA database value have to be attested advantages: - small and stable attestation - details of what was actually loaded or mapped are be hidden - the attesting system is not locked down The fact that details of what was actually loaded or mapped can be hidden is considered as an advantage as more detailed control can be achieved easily by asking device 'A' to compare its local IMA log against, e.g., a smaller, more restricted database. So it seems to me that by letting the attesting device do the database check, the advantages of the appraisal system and the current remote attestation systems could be combined. Does that somehow makes sense? Best regards Thomas On 08/27/2015 12:29 PM, Andreas Steffen wrote: > Hi Thomas, > > the basic principle of mutual attestation assumes that the peer > host has been compromised and cannot be trusted. Therefore it > doesn't make sense that device 'A' checks its IMA values against > its database, because if an attacker changes some system binaries > or libraries than he/she would also update the local database to > reflect the changed hash values. The assumption is that if > device 'A' has been compromised, device 'B' is still clean and > will be able to detect the changes on 'A' by using its untampered > database. > > Best regards > > Andreas > > On 27.08.2015 10:12, Thomas Strobel wrote: >> Hi Andreas, >> >> thanks a lot for the documentation! >> >> Just for my understanding, for the attestation a device 'A' sends its >> IMA log to the other side 'B', and then 'B' checks the log against its >> local database? If that is the case, would it be possible that device >> 'A' checks its IMA log against its local database and then only sends >> the hash of the database and the result of the check over to 'B'? As a >> database has to be available on both sides anyway, less data would need >> to be transmitted for the attestation. I don't know if the increase in >> trusted code on each side would be acceptable, though. >> >> >> Best regards >> >> Thomas >> >> >> >> On 08/16/2015 10:41 AM, Andreas Steffen wrote: >>> Hi Thomas, >>> >>> I documented the mutual attestation between two Raspberry Pi 2 >>> devices equipped with Infineon TPM 1.2 daughterboards: >>> >>> https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect#Mutual-Attestation-of-IoT-Devices >>> >>> >>> Best regards >>> >>> Andreas >>> >>> On 08/03/2015 08:56 PM, Thomas Strobel wrote: >>>> Hello Andreas, >>>> >>>> thank you very much for your help and the fast reply! Amazing, I'm >>>> looking forward to test it! :) >>>> >>>> Many thanks! >>>> Thomas >>>> >>>> >>>> On 08/03/2015 08:10 PM, Andreas Steffen wrote: >>>>> Hello Thomas, >>>>> >>>>> yes this is possible with strongswan 5.3.2. Have a look at my >>>>> presentation given at the 2015 TCG Members Meeting in Edinburgh: >>>>> >>>>> https://www.strongswan.org/docs/TCG_Edinburgh_2015.pdf >>>>> >>>>> The only thing you have to do is to load the tnc-imc and tmc-imv >>>>> plugins on both the TNC client and TNC server and of course the >>>>> needed IMCs and IMVs (for attestation usually the OS and Attestation >>>>> IMC plus the Attestation IMV). In order to activated the mutual >>>>> attestation capability set the following parameter in strongswan.conf >>>>> >>>>> charon { >>>>> plugins { >>>>> tncss-20 { >>>>> mutual = yes >>>>> } >>>>> } >>>>> } >>>>> >>>>> Best regards >>>>> >>>>> Andreas >>>>> >>>>> On 03.08.2015 19:42, Thomas Strobel wrote: >>>>>> Hello everyone, >>>>>> >>>>>> being new to the mailing list, I first want to thank everyone >>>>>> that is or >>>>>> was involved in developing strongswan as open source project, it's >>>>>> amazing! Thanks! >>>>>> >>>>>> Now my question. I'm thinking of using strongswan to secure P2P >>>>>> networks >>>>>> with mutual TNC remote attestation. Does strongswan support that use >>>>>> case? I mean, is it possible that both sides act as TNC client and >>>>>> server at the same time, and that a connection is only >>>>>> established after >>>>>> both sides verified the integrity of the other side? >>>>>> >>>>>> Many thanks >>>>>> Thomas >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> https://lists.strongswan.org/mailman/listinfo/users >>>>>> >> > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
