Logging System for Longlifetime

Transcription

1 Logging System for Longlifetime Data Validation!

2 Lifetime of data vs. signing key Lifetime of a data packet! depends on data usage! may exist for a long time! even forever! Lifetime of a signing key! must be limited! 2

3 How to maintain long-lived data Re-sign data with a new key! maintenance is complicated! key rollover! publishing re-signed data! Can we sign data once and leave it alone?! post-facto validation! validate data with an expired key?! 3

4 Post-Facto Validation Key was valid at the moment of signing! though it is invalid now! Check if the signature was generated during the valid period of the key! Can we have a time machine to go back?! a logging system may help!! 4

5 What to log? Assume we have a honest logger! Given a long-lived data! data name: retrieve data when necessary! data digest: integrity checking! signing timestamp! But also signing key! alice key validity root key validity Add /ndn/key Add /ndn/ucla/alice/key Validate Data1 Logger Timeline Add /ndn/ucla/key Add Data1 signed by /ndn/ucla/alice/key ucla key validity Add Data2 signed by /ndn/ucla/alice/key Validate Data2 5

6 Secure logger A trusted third party?! not every one will trust the same third party! no entity lasts forever! Publicly auditable logger! anyone can audit the logger! data signers, data consumers, certificate issuers, independent third parties,! force logger to behave honestly! tamper-evident log! 6

7 Tamper-Evident Log Hash chain! Bitcoin! simple, space effient! slow to check! MerkleTree! Certificate Transparency! efficient checking! hash1 hash2 hash3 hashn slot1 slot2 slot3 slotn hashk, hash1, 0 hash1, 2 hash1, N hash00 hash01 hash02 hash0n slot0 slot1 slot2... slotn 7

8 ! MerkleTree in NDN A MerkleTree consists of sub-trees! Each sub-tree! fixed by its root! easy to verify! fixed by its index (level, seqno)! easy to retrieve! once complete, become frozen! can be cached! 3, 0 1, 0 1, 2 1, 4 1, 6 8

9 Road Map Stage 1 (Partially done)! trusted logger! single logger! single trust model! Stage 2 (TODO)! scalable merkle tree! multiple loggers! Stage 3 (TODO)! gossip protocols!

10 Stage 1

11 Log a signature Self-signed signature! only for trust anchor! logger should watch trust anchor changes and actively log new anchor! Non-self-signed signature! logged on demand! signature must be valid at the moment of logging! signer certificate must have been logged before! timestamp must satisfy the validity requirements!

12 Trust Anchor Name:! /<AnchorName>/[SeqNo]/KEY/[KeyHash]/[Version]! SeqNo! key rollover! Self-Signed! Logger requires a trust anchor list!

13 Sub-tree Data Name:! complete sub-tree! /<logger_name>/[level]/[seqno]/complete/[roothash]! incomplete sub-tree! /<logger_name>/[level]/[seqno]/[nextleafseqno]/[roothash]! MetaInfo! ContentType: Data! FreshnessPeriod:! complete: N/A! incomplete: 60 sec! Content! concatenated hash of 32 leaves! for SHA-256, 32*32=1024 bytes! Signature! DigestSha256!

14 Leaf Data Name:! /<logger_name>/leaf/[seqno]/[hash]! hash: used as the hash of merkle tree leaf! MetaInfo! ContentType: Data! FreshnessPeriod:! complete: N/A! Content! a list of TLVs! data name (with implicit digest)! timestamp (Unix time)! leaf seqno! signer leaf seqno! content hash is also the hash of the corresponding merkle tree leaf! Signature! DigestSha256!

15 Log Request Log request is expressed as an signed interest! Name! /<logger_name>/log/[original_data_name]/[signer_seqno]/<sig_components>! original data name contains implicit digest! leaf with signer_seqno should contain the signer cert that matches the KeyLocator of the original data.! only authorized user can submit the log request! for example, any legitimate users on the NDN test bed! MetaInfo:! FreshnessPeriod should be long enough for logger to respond the the request! logger needs to retrieve the original data! optimization: encode original data in request name to avoid data fetching! A signer cert must be logged before the data! Response to a log request! no response to request made by unauthorized user! result code:! 0 for accepted! others for rejected! result seqno (when code == 0)! result msg (when code!= 0)!

16 Trust Anchor Assume:! one always know current trust anchor! Current trust anchor asserts its previous anchors by publishing a data packet precedents! contains each precedent s! corresponding leaf data! corresponding logger root hash! in time order! signed by current trust anchor! Expired data validation:! determine the previous trust anchor! request a list of intermediate certificates and corresponding timestamps to authenticate data! certificates comply with the trust model! timestamps comply with validity requirements!

17 Remaining Work Client side! auditor! log requester! data verifier!

18 Stage 2

19 Multiple Loggers Multiple loggers for the same purposes! same trust anchor & trust model! different writers! Loggers may serve different purposes! different namespaces, different trust models! e.g., each organization may have its own logger to log their own data! Loggers synchronize with each other! improve redundancy! automatically audit each other! e.g., using/extending ChronoSync! each logger has its own prefix & seqno! 19

20 Scalable Merkle Tree Store log & data separately! Loggers maintain log! Sub-loggers/users maintain actual data! no need to retrieve log for unavailable data! Sub-loggers/users cannot change actual data! digest is fixed in log! Sub-loggers/users may even keep a sub-tree! contain a sub-logger/user s own data! could be incomplete! root digest is fixed in log!! Logger's MerkleTree Use's actual data Sub-Tree Sub-Tree Sub-Tree Sub-Tree 20

21 Stage 3

22 Gossip Protocol Untrusted logger! logger s behavior is auditable! clients exchange their own knowledge about the root digest of logger through a gossip protocol!