[strongSwan] mutual TNC attestation

[Thomas Strobel]

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
>>>>>> Users at lists.strongswan.org
>>>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>>>
>>
>