Fwd: october 2003 meeting minutes (DC)
>Jim asked me to post the meeting from the october meeting in DC.
>
>Here they are,
>Fabio
Minutes, IEEE SISWG Standard meeting.
------------------------------------
Washington DC, Oct 30, 2003.
Attendeeds:
-----------
Jim Hughes - StorageTek
Serge Plotkin - Decru
Fabio - Cisco
Dalit Naor - IBM
Petri Vaananen - Utimaco
Shai Halevi - IBM (by phone)
Clement - Kasten Chase
Utimaco Company is in Boston.
Main company in Germany. The company is encrypting disk (software
and hardware). The company develops their own toolkits as well,
together with the Reijndel's (?) group at the Univ. of Lowen. The IBM
box is used to store the keys.
Agenda:
-------
Introduction
Draft documents
EME Mode
Sample Code
Key Escrow
Other docs?
New business
OSD
Next meeting
Shai's draft
In the mode of operations, there are GF(2) operations. Creation of
i, 4i, 8i ... in software is efficient (128 bit word shift and
XOR); Figure 4.2 in document is the C code for doing that. We
should refer to the byte order in the NIST AES document. We
reference in order that matters for the multiple by 2 procedure
(shift left or right). That's the only place where it matters.
Other things are the block order in the sector. Byte 0-15 are block #0.
Shai: what are the next steps with the document? it contains a
fairly detailed description of the implementation. There are
sections in the template that are not written.
Going over Shai's document
In Scope and purpose, add:
- motivation
- Goals
- Requirements
Add abstract (similar to Shai's paper abstract)
Add a reference to the published paper - in the Appendix: Informative
Add a reference to the stadard for AES; the document we are producing
is intended for specifying the
transformation in the spirit of the AES standard.
What about specifying the format? will it be described in a
different document? yes.
Equivalent to AES, the EME could be used by other standards.
Sector means 512 bytes - not necessarily a sector on disk.
This draft should be named 'Draft proposal for a wide-block encryption'
There should be another document called 'Draft proposal for
Storage encryption' which is the 'format document'.
There should be another standard for r=1, with no specification
for block length. Motivation - more general object instead of a
disk block.
Yes another 'Key Escrow' document.
Regardless of how the key is extracted from the unit (since meta data
format is not specified), the vendor should provide methods to exchange the
keys. The key-exchange format should be an XML format including
ID - binary -
comment - text
key - binary (K1||K2 if two keys are used)
LBA range - (start, length)
tweak - initial value
Key origin - string (derived or full-entropy FIPS compliant device)
r =
Algorithm = (like 'EME_WITH_AES_R_32')
standard number
standard version
standard comment
This is typically a high value structure, therefore it should be protected.
For example, the XML key file should be signed, with SXML. Vendor
should provide integrity to the key file, using standard methods.
Need to get identifiers for the name of the algorithm.
The key-exchange format specifies only for the LBAs in the XML file.
All other LBAs (which are not included in the LBA range) are out of the scope of this document.
It can be very valuable to specify a protection profile, agreed upon by IEEE -
specifying what you are protecting against. This will allow testing of some
implementations.
r=1 can be done by using the first column of figure 4.1 but this
is not efficient. Can be done AES on the TWEAK and then XOR it (before and after)
so it costs 1 AES and one multiplication.
Tweak
| p1
AES (k1) |
|
2x
|----------xor
| |
| AES(k2)
| |
|----------xor
|
c1
OR
p1
|
L ---xor
|
AES
|
T ---xor
|
AES
|
L ---xor
|
c1
Serge is concerned that this mode won't pass FIPS certification
since you use the same key (k1 and k2). Wants to allow 2 keys, but these keys may be equal.
Shai and Jim - this is not a FIPS mode!
Jim wants the reference to this requirement from FIPS.
Sample code is embedded in the document.
Shai also wrote a program to generate test vectors.
OSD Issues:
-----------
If the encryption is done at the client, then there is a
read-modify-write penalty since the encryption is done in blocks.
Every change must re-encrypt the block.
What about the holes? you don't want to decrypt the o's, want to
maintain the semantics of the holes.
Remote copy and Flash copy. Should not require decryption and
re-encryption.
Keeping a key for an object on a physically secure platform is
not feasible (expensive). Therefore, must support a mechanism for
storing these keys - either on a separate disk or in the ObS (in
a special object) - or object keys derived from a single 'ObS'
key.
Can the MDS become a repository for sensitive/replicated data?
Action items:
-------------
Overview document - Jim
Wide Block Encryption standard - Shai
sample code - Jim
r=1 document - Serge
key escrow - Dalit
Dalit will try to start a discussion on OSD encryption before the meeting.
Target date January 30th.
Next meeting
-------------
February 25, Wednesday in the bay area. Probably at Cisco campus.
(RSA conference is in Feb 23-27 in San Francisco).