Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote: So it can provide confidentiality but it CANNOT provide integrity protection. Yes, it provides confidentiality and via encryption it provides certain level of integrity protection. Data cannot be modified without being detected. Decryption will result in garbage... It should, but it is not cryptographic integrity protection. Moreover, you can revert ciphertext sector content. Btw I think dm-integrity doesn't solve the reply problem as well. (IOW can you replace/revert both data and hash, still using the same key in keyring, without dm-integrity able to detect it?) In dm-verity, root hash will change after such data tampering. Obvious question: can be dm-verity extended to provide read-write integrity? I think re-calculating hash trees all the time and syncing block hashes and tree itself is heavier operation... Then why not extend dm-verity to use you hash format? There are options for that and we can redefine table line if necessary. (You are duplicating a lot of code here otherwise, not counting userspace yet.) Whatever, I shortly read the code and have some notes. First, device-mapper is variable system, you can stack devices in arbitrary order. Unfortunately, this is something what can be dangerous in crypto, here you can e.g. - do mac (integrity) then encrypt - do encrypt, then check integrity In many implementations mac-then-encrypt system was not secure. Are we sure that it cannot provide side channels here? Note read-only integrity target (like dm-verity) is specific case, you should not be able to run any chosen ciphertext attacks here, it is read-only device. In fact, I am not sure if we should provide separate read-write block integrity (wihtout encryption) target at all. Either it should use standard mode of authenticated encryption (like GCM) or data integrity should be upper layer business (which knows better which data really need integrity checking and which areas are just unused garbage. If you consider hashing and encryption as heavy operation you should minimize it to only really used area - and only upper layer know about real used data content.) (Again, this is different for read-only target, where it usually uses compressed RO fs image which uses all available space.) 1) discards It seems the dm-integrity target doesn't solve problem with discards. If you send discard request to underlying device, data content of discarded area is undefined (or zeroed if discards zeroes data) but is is definitely invalid form the dm-integrity point of view. And you are allowing discard IOs there. I am not sure what should happen, but the behaviour should be documented (at least) or disabled. 2) All used hash algorithms must be configurable. From your doc: +While NIST does recommend to use SHA256 hash algorithm instead of SHA1, +this does not apply to HMAC(SHA1), because of keying. +This target uses HMAC(SHA1), because it takes much less space and it is +faster to calculate. There is no parameter to change hmac hash algorithm. While this is technically true, http://csrc.nist.gov/groups/ST/hash/policy.html disallowing use of another hash algorithm is wrong, and in fact it is regression in comparison with dm-verity (which already implements all needed calculations and uses hash name as table line option). +HMAC(SHA1) size is 20 bytes. So every 4k block on the integrity device can +store 204 hmacs. In order to get the required size of the integrity device, +it is necessary to divide data device size by 204. Why are you hardcoding block and hash sizes? Again, dm-verity have this configurable with some good default. ditto for kernel keyring: + const char *hmac_algo = hmac(sha1); /* uncompromized yet */ 3) I like that this target can use kernel keyring, in fact, we should implement similar option to dm crypt/verity. But the target should not be limited to use TPM keys only. (And key is stored directly in kernel memory later for hash calculation anyway allowing hw attacks reading it from RAM.) 4) reboot notifier cannot be used this way in generic storage stacking IMHO, but I think there was discussion with Mikulas already http://www.redhat.com/archives/dm-devel/2012-March/msg00164.html 5) output target table should not translate device to device symbolic names Anyway, code can be changed. But the high level questions remains... Milan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On Tue, Sep 25, 2012 at 3:15 PM, Milan Broz mb...@redhat.com wrote: On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote: So it can provide confidentiality but it CANNOT provide integrity protection. Yes, it provides confidentiality and via encryption it provides certain level of integrity protection. Data cannot be modified without being detected. Decryption will result in garbage... It should, but it is not cryptographic integrity protection. Moreover, you can revert ciphertext sector content. Btw I think dm-integrity doesn't solve the reply problem as well. (IOW can you replace/revert both data and hash, still using the same key in keyring, without dm-integrity able to detect it?) Yes, reply problem is the same. It is context free. In dm-verity, root hash will change after such data tampering. yes, I know. Obvious question: can be dm-verity extended to provide read-write integrity? I think re-calculating hash trees all the time and syncing block hashes and tree itself is heavier operation... Then why not extend dm-verity to use you hash format? There are options for that and we can redefine table line if necessary. dm-integrity does not use hash tree. switching tree to hmac needs to recalculating everything. It simply does not make sense. (You are duplicating a lot of code here otherwise, not counting userspace yet.) All targets have similarities here and there. At the end they work in different way. From source code point of it is clearer to keep them separately as they do things in different way. It does not require any user space tools. Whatever, I shortly read the code and have some notes. First, device-mapper is variable system, you can stack devices in arbitrary order. Unfortunately, this is something what can be dangerous in crypto, here you can e.g. - do mac (integrity) then encrypt - do encrypt, then check integrity In many implementations mac-then-encrypt system was not secure. Are we sure that it cannot provide side channels here? Note read-only integrity target (like dm-verity) is specific case, you should not be able to run any chosen ciphertext attacks here, it is read-only device. In fact, I am not sure if we should provide separate read-write block integrity (wihtout encryption) target at all. Either it should use standard mode of authenticated encryption (like GCM) or data integrity should be upper layer business (which knows better which data really need integrity checking and which areas are just unused garbage. If you consider hashing and encryption as heavy operation you should minimize it to only really used area - and only upper layer know about real used data content.) (Again, this is different for read-only target, where it usually uses compressed RO fs image which uses all available space.) Again, as it is written in cover letter. It can be used for certain use cases, which does not want encryption for performance or data transforming reasons... 1) discards It seems the dm-integrity target doesn't solve problem with discards. If you send discard request to underlying device, data content of discarded area is undefined (or zeroed if discards zeroes data) but is is definitely invalid form the dm-integrity point of view. And you are allowing discard IOs there. I will check about it. I am not sure what should happen, but the behaviour should be documented (at least) or disabled. 2) All used hash algorithms must be configurable. dm-integrity uses HASH and HMAC together for HW enabling reasons... Hash is calculated using async API and HMAC is sync. Hash algorithm is configurable. There is a target parameter for that dev_path offset hdev_path hoffset hash_algo key_desc [opt_params] HMAC is different... Because of using key, hmac(sha1) is not vulnerable to attacks as sha1... There is currently absolutely no reason to use hmac(sha256) or other. hmac(sha1) is absolutely enough... Before I used only sync API and it was a parameter for hmac only. Now there is hash only parameter.. But this is not an issue. I could easily have a parameter for hmac.. From your doc: +While NIST does recommend to use SHA256 hash algorithm instead of SHA1, +this does not apply to HMAC(SHA1), because of keying. +This target uses HMAC(SHA1), because it takes much less space and it is +faster to calculate. There is no parameter to change hmac hash algorithm. While this is technically true, http://csrc.nist.gov/groups/ST/hash/policy.html disallowing use of another hash algorithm is wrong, and in fact it is regression in comparison with dm-verity (which already implements all needed calculations and uses hash name as table line option). +HMAC(SHA1) size is 20 bytes. So every 4k block on the integrity device can +store 204 hmacs. In order to get the required size of the integrity device, +it is necessary to divide data device size by 204. This is just an example to understand space
[PATCH 0/1] dm-integrity: integrity protection device-mapper target
There are two existing offline integrity models: file level integrity (linux-integrity subsystem EVM/IMA-appraisal) and block level integrity (dm-verity, dm-crypt). This patch provides a new block level method called device-mapper integrity target (dm-integrity), which provides transparent cryptographic integrity protection of the underlying read-write block device using hash-based message authentication codes (HMACs). The HMACs can be stored on the same or different block device. dm-integrity uses an encrypted key type, stored on the kernel keyring, to obtain a secret key for use in cryptographic operations. Encrypted keys are never exposed in plain text to user space. The encrypted keys are encrypted using master key, which can either be a user defined or trusted key type. The secret key, which is usually device specific, binds integrity data to the device. As a result data blocks and corresponding HMACs cannot simply be copied over from other file systems. EVM/IMA-appraisal provides file level integrity protection. The advantages are that it is policy based, file measurements are available for remote attestation, and files can be digitally signed to provide authenticity. Both dm-verity and dm-crypt provide block level integrity protection. dm-verity provides block level integrity protection for read-only file systems, while dm-crypt provides block level integrity protection, with minimum penalty, for filesystems requiring full disk encryption. dm-integrity provides a lighter weight read-write block level integrity protection for file systems not requiring full disk encryption, but which do require writability. - Dmitry Dmitry Kasatkin (1): dm-integrity: integrity protection device-mapper target Documentation/device-mapper/dm-integrity.txt | 125 drivers/md/Kconfig | 12 + drivers/md/Makefile |1 + drivers/md/dm-integrity.c| 1019 ++ 4 files changed, 1157 insertions(+) create mode 100644 Documentation/device-mapper/dm-integrity.txt create mode 100644 drivers/md/dm-integrity.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote: Both dm-verity and dm-crypt provide block level integrity protection. This is not correct. dm-crypt is transparent block encryption target, where always size of plaintext == size of ciphertext. So it can provide confidentiality but it CANNOT provide integrity protection. We need extra space to store auth tag which dmcrypt cannot provide currently. dm-integrity provides a lighter weight read-write block level integrity protection for file systems not requiring full disk encryption, but which do require writability. Obvious question: can be dm-verity extended to provide read-write integrity? I would prefer to use standard mode like GCM to provide both encryption and integrity protection than inventing something new. Milan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On Mon, Sep 24, 2012 at 4:47 PM, Milan Broz mb...@redhat.com wrote: On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote: Both dm-verity and dm-crypt provide block level integrity protection. This is not correct. dm-crypt is transparent block encryption target, where always size of plaintext == size of ciphertext. Of course... It is just said in relation to integrity protection. It is said about encryption in following paragraphs... So it can provide confidentiality but it CANNOT provide integrity protection. Yes, it provides confidentiality and via encryption it provides certain level of integrity protection. Data cannot be modified without being detected. Decryption will result in garbage... We need extra space to store auth tag which dmcrypt cannot provide currently. dm-integrity provides a lighter weight read-write block level integrity protection for file systems not requiring full disk encryption, but which do require writability. Obvious question: can be dm-verity extended to provide read-write integrity? I think re-calculating hash trees all the time and syncing block hashes and tree itself is heavier operation... I would prefer to use standard mode like GCM to provide both encryption and integrity protection than inventing something new. As said, if encryption is considered heavy operation in term of CPU and battery usage and also if encryption is not desired for some reasons that would be an option. - Dmitry Milan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
