| |||||||||||||
Copy Offload - SecurityCopy Offload - SecurityPosted Apr 19, 2012 14:57 UTC (Thu) by feknight8 (guest, #84191)In reply to: Copy Offload by eternaleye Parent article: 2012 Linux Storage, Filesystem, and Memory Management Summit - Day 1
The Token == the data. Applications must treat the token in the same way they treat data (if you wouldn't give someone the data, then don't give them the token).
As for devices that build these tokens, yes, dumb designs are possible, as are dumb implementations or buggy implementations. All the standard can do it describe how it is supposed to work, and the standard makes the following statement about the contents of the token:
"The EXTENDED ROD TOKEN DATA field shall contain at least 256 bits of secure random number material (see 4.5) generated when the ROD token was created..."
Those "at least 256 bits" are contained within the 4096 bit structure - which also contains other information.
Sub-clause 4.5 states: "Secure Random numbers should be generated as specified by RFC 4086 (e.g., see FIPS 140-2 Annex C: Approved Random Number Generators)."
Therefore, the token contents are intended to be as secure as FIPS 140 can make it.
(Log in to post comments)
|
|||||||||||||