Commit 13cc85f1 authored by Mike Hibler's avatar Mike Hibler
Browse files

Quick thoughts on encrypted images.

parent 603b59f9
......@@ -43,6 +43,32 @@ Things to do for image*:
simple and have a single option and just treat things like the MBR
8. Encrypted images.
This would give us confidentiality. Images would be chunk-by-chunk
encrypted/decrypted using a runtime specified session key. I assume
we want to use symmetric crypto here, since it is faster. Note that
we would need to combine this with some other mechanism if we also want
to ensure integrity.
Imagezip would take as an argument a key (or a file from which to read
the key?) and in the code where it compresses, it can also encrypt
(encrypt before compression? after?) The resulting image is one in
which the chunk meta-data (header info: disk ranges contained, any
relocations) is not encrypted. Is this a problem? The block ranges
and relocations could give some hint as to what the image contains
(e.g., if block 16 is not in the list, it isn't a BSD filesystem since
that is where the superblock is). What the hell, we can independently
encrypt the header as well.
Imageunzip (and frisbee) will likewise take a new argument for the key
to be used. For frisbee this will be transferred "out-of-band" with
TMCD. While decryption could take place in a separate thread, I'm
inclined not to worry about it right now given that we are mostly working
with uniprocessor machines where there would be no advantage. Anyway,
imageunzip would collect a chunk, decompress and unencrypt it, and feed
it to the disk writer.
For integrity, we could use the signature-communicated-out-of-band
approach (#6 above), or we could include a single, coarser-grained
hash/checksum for each chunk.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment