Re: [Linux-ima-user] Endianness-dependent IMA field array hash

[Andreas S. <and...@st...>]

Hello,

just to make it clear. There is no problem with the length
fields in the raw binary measurement list

  /sys/kernel/security/ima/binary_runtime_measurements

being in host order since this list is handled by the local
Attestation Integrity Measurement Collector (IMC) which
has the same endianness as the underlying kernel. The
information which the Attestation IMC includes in the
integrity report (TCG TNC PTS Binding for the IF-M Protocol)
is the template hash of each measurement as it was extended into
PCR 10 (which with a current version 1.2 TPM is a 20 byte SHA-1 value).
Additional information included in the  integrity report is the
eventname (a modified absolute filename or boot_aggregate) and the hash
algorithm with which the file itself was hashed ("sha1:", "sha256",
etc.).

My only request is to convert the field lengths into network
order when they are actually hashed into the final measurement value:

  u32 field_data_len = htonl(field_data[i].len);

  rc = crypto_shash_update(&desc.shash,
              (const u8 *) &field_data_len,
               sizeof(field_data_len));

With this simple change the endianness of the client platform doesn't
have to be included in the integrity report (which would be an awful
kludge anyway).

A platform-independent template hash has also the big advantage that
the measurement values of [non-executable] configuration files would be
the same on all platforms.

Kind regards

Andreas

On 30.04.2014 23:43, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 19:40 +0200, Roberto Sassu wrote: 
>> On 04/30/2014 07:10 PM, Mimi Zohar wrote:
>>> On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
>>>> Hello,
>>>>
>>>>
>>>> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
>>>>> Hi Mimi,
>>>>>
>>>>> I'm currently updating strongSwan's remote attestation capability
>>>>> to include the new IMA-NG hash formats.
>>>
>>> Nice!
>>>
>>>> While inspecting the IMA
>>>>> source code I noticed that the hash of the template data computed
>>>>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
>>>>> endianness of the host platform:
>>>>>
>>>>>    rc = crypto_shash_update(&desc.shash,
>>>>>                (const u8 *) &field_data[i].len,
>>>>>                 sizeof(field_data[i].len));
>>>>>
>>>>> Since the attestation server reconstructs the template data hash
>>>>> from the SHA-1/SHA-256 file hash and absolute file name stored in
>>>>> the reference database I would be much happier if the 32 bit
>>>>> unsigned integer stored in field_data[i].len would be converted into
>>>>> platform-independent network order before these four bytes are
>>>>> included in the template hash. With the current code the attestation
>>>>> server must know the endianness of each of its clients in order to
>>>>> generate the correct hash value.
>>>>>
>>>
>>> Yes, I'm aware of this issue.
>>>
>>>> It is very good point. Measurement list should not depend on endianness.
>>>
>>> The measurement lists aren't network facing, but consumed by a userspace
>>> application/server.  The question is whether converting the securityfs
>>> binary/ascii measurement lists to network byte order is the
>>> responsibility of the kernel or should this be done by userspace
>>> application/server?
>>>
>>> CC'ing Roberto for his comments, as he's upstreamed OAT patches.
>>>
>>
>> Hi Mimi, all
>>
>> the TCG consortium defined a set of specifications so that
>> measurements can be arranged in a XML document. For IMA measurements
>> we found that the fields 'Type' and 'Image' of the object ValuesType
>> can be used to store respectively the template name and template data
>> in binary format (encoded in base 64).
>>
>> This part of the specifications can be found at the URL:
>>
>> http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf
>>
>> at page 11.
>>
>>
>>  From what I understand, an userspace tool that handles the remote
>> attestation protocol should take raw data as is and store it directly
>> in the integrity report. The advantage to do that is that userspace
>> tools do not need the ability to understand raw data, that are
>> interpreted by an analysis tool after doing the unmarshalling of the
>> report.
>>
>> So, I think that it is better to modify the IMA code to fix this issue.
> 
> Ok.  Besides the field length, is there any other data which should be
> defined in a platform independent format (eg. template_data_len)?
> 
> Mimi
> 
> 
> 

-- 
======================================================================
Andreas Steffen                         and...@st...
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==