439
edits
NSS Shared DB: Difference between revisions
Jump to navigation
Jump to search
→Special coding for MACed entries
| Line 239: | Line 239: | ||
MACs are not processed for the legacy database. | MACs are not processed for the legacy database. | ||
Entries which require MACs require that the user be logged into the token to write or modify the entry. | Entries which require MACs require that the user be logged into the token to write or modify the entry. On readback, they are not checked unless the user is logged in. | ||
MACS are formed by concatenating the object id (encoded as a database ULONG) with the attribute type (also encoded as a ULONG) and with the atttribute data. This concatenation is fed into a SHA1 HMAC keyed with the token key described in the 'Special coding for encrypted entries'. The resulting Mac is stored in | Tokens which have no key database (and therefore no master password) do not | ||
have any stored MACs. | |||
Attributes that are MACed are: | |||
# Trust object hashes and trust values | |||
# public key values. | |||
Certs themselves are considered properly authenticated by virtue of their | |||
signature, or their matching hash with the trust object. | |||
MACS are formed by concatenating the object id (encoded as a database ULONG) with the attribute type (also encoded as a ULONG) and with the atttribute data. This concatenation is fed into a SHA1 HMAC keyed with the token key described in the 'Special coding for encrypted entries'. The resulting Mac is stored in a special table in the key database called the | |||
'metadata'. This table could store other types of meta data as well in the | |||
future. Currently the password check is also stored in the metadata table. | |||
Integrity entries are indexed by the string | |||
sig_[cert/key]_{ObjectID}_{Attribute} | |||
Where cert/key indicates which logical database the actual object is stored in, | |||
{ObjectID} is the id of the object and {Attribute} is the attribute this | |||
integrity entry is for. | |||
Entries are check when the user tries to get and attribute. Once the attributes | |||
are fetched, GetAttributes loops through the attributes looking for attributes | |||
that require integrity checks. When such an attribute is found, the integrity | |||
check entry is fetched and an HMAC is calculated for the attribute. If the | |||
attribute matches the integrity entry, processing proceeds. If it doesn't that | |||
attribute data is cleared and CKR_SIGNATURE_INVALID is returned. | |||
Integrity checks are PBMAC1 data structures defined in pkcs5. Since pkcs5 v1 | |||
had not integrity checks and pkcs12 has not definition for storing purely mac | |||
data,the shared DB integrity checks uses pkcs5 v2 to store that pbe and mac | |||
data. This patch turns on pkcs5 v2 as a result. The PBMAC1 is using SHA256 for | |||
a MAC operation. The hmac data is formed by taking an hmac over the objectId, | |||
attribute type, and data value of the attribute. | |||
===== Database coherency issues ===== | ===== Database coherency issues ===== | ||