Usable Security of Named Data Networking Yingdi Yu 1 Traditional - - PowerPoint PPT Presentation

usable security of named data networking
SMART_READER_LITE
LIVE PREVIEW

Usable Security of Named Data Networking Yingdi Yu 1 Traditional - - PowerPoint PPT Presentation

Usable Security of Named Data Networking Yingdi Yu 1 Traditional communication model of Internet Speaking to a host end-to-end channel Communication security container-based authenticity: X.509, Certificate


slide-1
SLIDE 1

Usable Security of Named Data Networking

Yingdi Yu

1

slide-2
SLIDE 2

Traditional communication model of Internet

  • Speaking to a host
  • end-to-end channel
  • Communication security
  • container-based authenticity: X.509, Certificate Authority
  • channel-based confidentiality: IPSec, TLS/SSL

2

slide-3
SLIDE 3

New communication vs. Old security

  • Content Distribution Network (CDN)
  • multiple containers to secure
  • no end-to-end channel

3

?

slide-4
SLIDE 4

New communication vs. Old security

4

  • Delay Tolerant Network (DTN)
  • temporary data container
  • no instantaneous end-to-end channel

?

slide-5
SLIDE 5

New security model is desired!

5

  • No trustworthy container, no end-to-end encrypted

channel

  • Data-centric security: let’s secure data directly!
  • authenticate data rather than container
  • encrypt data instead of channel
slide-6
SLIDE 6

Named Data Networking

6

  • Data-centric communication primitives
  • retrieve data by name rather by container address
  • Interest Packet: expressed by consumer, forwarded according

to name

  • Data Packet: made by producer, forwarded along reverse path

Consumer Consumer Producer /ucla/cs/frontpage /ucla/cs/frontpage/v1

slide-7
SLIDE 7

Efficient & flexible data delivery

7

  • Data can be picked anywhere
  • in-network caching
  • Does not require instantaneous communication
  • producer can go offline
  • store pre-created data in third party storage

Consumer Consumer Producer

slide-8
SLIDE 8

Built-in data authenticity

  • Per packet signature
  • privilege separation: different data signed by different keys
  • Retrieve public key as data
  • same authentication procedure
  • Data carrying public key is a certificate
  • more powerful

8 Name: /ucla/cs/alice/thesis/v_3/s_8 Content: ... SignatureInfo: KeyLocator: /ucla/cs/alice/KEY/2 ValidityPeriod: [2015/5/2, 2016/5/2) ... Signature Bits: ... NDN Data Packet Name: /ucla/cs/alice/KEY/2 Content: 6d:32:8d:23:a9:b0:89:... SignatureInfo: SignatureType: RSA-SHA256 KeyLocator: /ucla/cs/KEY/7 ValidityPeriod: [2015/1/1, 2017/1/1) ... Signature Bits: cd:ca:70:72:7b:ff:a8:... NDN Certificate X 509 Certificate Subject Name Subject Public Key Info Certificate Signature Algorithm Issuer Name Validity Period Certificate Signature

slide-9
SLIDE 9

But how to utilize those features?

  • Developers turn off security as the first step
  • fake signature
  • skip authentication
  • wish no one is eavesdropping
  • Can we make security easier for developers?
  • automate data authentication
  • automate data encryption
  • minimize maintenance overhead

9

slide-10
SLIDE 10

Outline

10

Automating Data-Centric Authenticity Authenticating Long-Lived Data Automating Data-Centric Confidentiality

slide-11
SLIDE 11

Outline

11

Automating Data-Centric Authenticity Authenticating Long-Lived Data Automating Data-Centric Confidentiality

slide-12
SLIDE 12

Trust chain

  • Recursively retrieve key until reach a trust anchor
  • a pre-trusted key
  • Constrained by trust derivation rules
  • is data (or key) signed by a trusted producer (or issuer) ?
  • Validate signature

12 Name: /ucla/cs/KEY/7 Content: ... Signature: KeyLocator: /ucla/KEY/5 Data packet (key) Trust Anchor /ucla/KEY/5

Trust Model

Name: /ucla/cs/yingdi/thesis/v_3/s_8 Content: ... Signature: KeyLocator: /ucla/cs/yingdi/KEY/2 Data packet (target) Name: /ucla/cs/yingdi/KEY/2 Content: ... Signature: KeyLocator: /ucla/cs/KEY/7 Data packet (key)

slide-13
SLIDE 13

Diversity of trust models

  • Trust model could be simple in some cases
  • Application specific in general
  • capability-based trust
  • identity-based trust
  • role-based trust

13 /MyHome /MyHome/temperature /MyHome/album /MyHome/msg thermometer family member /MyHome/temperature/2016/5/2/15/30 /MyHome/album/2015/yosemite/2 /MyHome/msg/bob/13 /MyHome/temperature/KEY /MyHome/member/bob/KEY . (root) .com .edu .org google.com ucla.edu cnn.com

slide-14
SLIDE 14

NDN insight

  • Name is a general expression
  • can refer to identity, capability, role, …
  • Any trust model can be expressed as a list of

relationship between data name and key name

  • Data authentication can be done correctly and easily if

we have

  • a name-based policy language to express trust model
  • a library to perform authentication according to the policy

14

Schematize the trust Automate data authentication

slide-15
SLIDE 15

Describe trust relationship in name

  • Relationship between data and key names
  • Generalized as name pattern
  • Regex-based syntax

15 family member signs

/My/home/msg/bob/13 /My/home/msg/alice/15 /My/home/member/bob/KEY /My/home/member/alice/KEY

/My/home/member/bob/KEY /My/home/msg /My/home/msg/bob/13

home_prefix + “home” + “msg” + user + msg_id home_prefix + “home” + “member” + user + “KEY”

signs

(<>*)<home><msg>([user_id])<> \1<home><member>\2<KEY>

signs /My/home/msg/frank/13

slide-16
SLIDE 16

Trust schema

Rule ID Data Name Key Name msg (<>*)<home><msg>([user])<> \1<home><member>\2<KEY>

16

album (<>*)<home><album><><><> \1<home><member>[user]<KEY> member (<>*)<home><member>([user])<KEY> \1<home><KEY> temp (<>*)<home><temperature><><><><><> \1<home><temperature><KEY> therm (<>*)<home><temperature><KEY> \1<home><KEY>

/My/Home /My/home/temperature /My/home/album /My/home/msg /My/home/msg/bob/13 family member /My/home/member/bob/KEY /My/home/album/2015/yosemite/2 thermometer /My/home/temperature/KEY /My/home/temperature/2016/5/2/15/30

root (<>*)<home><KEY> /My/home/KEY 30:b4:82:9c:45:…

/My/home/KEY signs signs signs signs signs

slide-17
SLIDE 17

Trust chain construction

Rule ID Data Name Key Name msg (<>*)<home><msg>([user])<> \1<home><member>\2<KEY>

17

album (<>*)<home><album><><><> \1<home><member>[user]<KEY> member (<>*)<home><member>([user])<KEY> \1<home><KEY> temp (<>*)<home><temperature><><><><><> \1<home><temperature><KEY> therm (<>*)<home><temperature><KEY> \1<home><KEY> root (<>*)<home><KEY> /My/home/KEY 30:b4:82:9c:45:…

Name: /My/home/album/2015/yosemite/2 Content: ... Signature: KeyLocator: /My/home/member/bob/KEY Data packet (target) Name: /My/home/member/bob/KEY Content: ... Signature: KeyLocator: /My/home/member/bob/KEY Data packet (key) Name: /My/home/member/bob/KEY Content: ... Signature: KeyLocator: /My/home/KEY Data packet (key) Trust Anchor /My/home/KEY

slide-18
SLIDE 18

Re-usability

Rule ID Data Name Key Name msg (<>*)<home><msg>([user])<> \1<home><member>\2<KEY>

18

album (<>*)<home><album><><><> \1<home><member>[user]<KEY> member (<>*)<home><member>([user])<KEY> \1<home><KEY> temp (<>*)<home><temperature><><><><><> \1<home><temperature><KEY> therm (<>*)<home><temperature><KEY> \1<home><KEY>

family member thermometer

root (<>*)<home><KEY> /My/home/KEY 30:b4:82:9c:45:…

/My/Home /My/home/temperature /My/home/album /My/home/msg /My/home/msg/bob/13 /My/home/member/bob/KEY /My/home/album/2015/yosemite/2 /My/home/temperature/KEY /My/home/temperature/2016/5/2/15/30 /My/home/KEY

different trust anchor for different home

root (<>*)<home><KEY> /Other/home/KEY 9c:45:30:b4:82:…

/Other/home/msg/bob/13 /Other/home/album/2015/yosemite/2 /Other/home/temperature/KEY /Other/home/member/bob/KEY /Other/home/temperature/2016/5/2/15/30 /Other/Home /Other/home/temperature /Other/home/album /Other/home/msg /Other/home/KEY

slide-19
SLIDE 19

Automated Signing

  • Signing Interpreter
  • Determine signing key
  • Request certificate if

needed

19 Automated Certificate Issuance System

<My><home><member>[user]<KEY> /My/home/album/2014/zion/1

Find matching rule 1 Derive key name for the article 2 Lookup key in TPM 3 Sign data 4

/My/home/member/bob/KEY (<>*)<home><album><><><> \1<home><member>[user]<KEY> /My/home/album/2014/zion/1

album member

Signing Interpreter unsigned data signed data TPM

root

album msg member temp therom

slide-20
SLIDE 20

Implementation

  • Available in all the NDN platform libraries
  • ndn-cxx: http://www.github.com/named-data/ndn-cxx
  • NDN-CCL: http://named-data.net/codebase/platform/ndn-ccl/
  • Powers data and interest authentication in:
  • NFD: NDN Forwarding
  • NLSR: NDN Link State Routing Protocol
  • NDNS: NDN Domain Name System
  • Repo-ng: NDN Data Repository
  • ChronoChat: server-less multi-party chat application over NDN

20

slide-21
SLIDE 21

Summary

  • Trust schema is a general expression of NDN trust

model

  • can be executed by any entity
  • Trust schema is in text format
  • can be distributed as data packets
  • A trust schema represents a security design pattern
  • regulate the behavior of applications
  • a set of common trust schemas

21

slide-22
SLIDE 22

Outline

22

Automating Data-Centric Authenticity Authenticating Long-Lived Data Automating Data-Centric Confidentiality

slide-23
SLIDE 23

Lifetime Mismatch

  • Data lifetime is usually longer than its signature
  • crypto algorithm, key compromise, …
  • Periodical re-signing is not the solution
  • will not scale in long term
  • data may outlive its producer
  • not a problem in channel based security
  • After fact validation
  • verify signature validity at the time of production

23 data is produced data is retrieved signature expire time

slide-24
SLIDE 24

How to rollback the clock?

  • Timestamp service
  • producer requests timestamp of data from the service
  • provide existence proof of data at a given time point
  • Design challenges
  • how to tell the timestamp service is honest?
  • scale with the number of timestamp records

24 Consumer Verifiable Timestamp Service (VTS) Producer

slide-25
SLIDE 25

Verifiable timestamp

  • Timestamp service periodically

publishes a timestamp bundle

  • containing data received during

the time period

  • Producer requests including

its data in a bundle

  • Existence verification
  • check whether data is in the

corresponding bundle

25 t0 t1 t2 t3 t4 t5 /time/t0 /time/t1 /time/t2 /time/t3 /time/t4 Producer Timestamp Service Could you timestamp my data?

  • Sure. I will include it in

timestamp bundle 3. timeslot 3 timeslot 4 Publish timestamp bundle 3 Retrieve timestamp bundle 3

slide-26
SLIDE 26

timeslot 98 ... Retrieve timestamp bundle 98 Publish timestamp bundle 98 timeslot 50 ... Retrieve timestamp bundle 50 Publish timestamp bundle 50 Producer Timestamp Service timeslot 3 Retrieve timestamp bundle 3 Publish timestamp bundle 3

Consistent timestamp

  • Consistence verification
  • check whether the timestamp

service modified the history

  • A naïve solution: hash chain
  • each timestamp bundle fixes all

the previous timestamp bundles

  • consumers and producers can

verify consistency periodically

26 t0 t1 t2 t3 t4 t5 /time/t0 /time/t1 /time/t2 /time/t3 /time/t4 /time/t1 t0 t1 t2 t3 t4 t5 /time/t0 null /time/t1 h0 /time/t2 h1 /time/t3 h2 /time/t4 h3 t0 t1 t2 t3 t4 t5 /time/t0 null /time/t1 h0 /time/t2 h'1 /time/t3 h'2 /time/t4 h'3

is it consistent with bundle 3? is it consistent with bundle 50?

slide-27
SLIDE 27

Reduce verification overhead

  • Hash chain: O(m)
  • m: number of timeslots
  • 10-min timeslots for 20 years: 106
  • k-ary Merkle tree:
  • root hash as the state
  • existence verification:
  • O(logkm)
  • consistence verification:
  • O(logkm)
  • 20 years timestamps
  • 4 hash computations for 32-ary

Merkle tree

27 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n0,5 n0,6 n1,2 n1,3 n2,1 n3,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n0,5 n0,6 n1,2 n1,3 n2,1 n3,0 n0,0 n0,1 n0,2 n1,0 n1,1 n2,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n0,5 n0,6 n1,2 n1,3 n2,1 n3,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n0,5 n0,6 n1,2 n1,3 n2,1 n3,0

hi,n = H(hi-1,nk^i|hi-1,nk^i+1|…|hi-1,nk^i+k-1)

slide-28
SLIDE 28

Verification proof as data

  • Proof is a pre-determined node set
  • simply publishes each node as data
  • consumer look up nodes necessary

for verification

  • Update nodes after adding a new

timestamp bundle

  • complete nodes are not changed
  • at most one incomplete node at

each layer

28 n0,0 n0,1 n0,2 n1,0 n1,1 n2,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n1,2 n2,1 n3,0 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n1,2 n2,1 n3,0 n0,5 n0,0 n0,1 n0,2 n1,0 n0,3 n1,1 n2,0 n0,4 n0,5 n0,6 n1,2 n1,3 n2,1 n3,0

slide-29
SLIDE 29

Name: /TimestampTree/ 3 / 3 / 0 /e8bc75.. Content: Signature: ... f189a0.. 3fa353.. 3 children 279021..

Node data

  • Naming convention
  • uniquely identify a node in a particular state
  • Given a time point, the name
  • f any node is determined
  • 29

3,0 2,0 2,1 1,64 2,2 2048, 2049

... ... ...

Index: 0, 1, ...... , 32, 1,0

...... ......

/[tree_prefix]/[completeness]/[layer]/[index]/[hash] /TimestampTree/2050/1/64 /TimestampTree/complete/2/0 /TimestampTree/2050/2/2

Name: /TimestampTree/complete/ 2 / 1 /9900a.. Content: Signature: ... a2ed8b.. 7ac9dd.. 4bb231.. ... 32 children hashes

/TimestampTree/2050/3/0

slide-30
SLIDE 30

Node retrieval

  • Nodes at higher layers are cached
  • more frequently retrieved
  • root node cached almost

everywhere

  • Complete nodes can be served by dummy storage
  • balance traffic by routing prefix

30 Timestamp Service Data storage /TimestampTree/complete /TimestampTree ... ...

slide-31
SLIDE 31

Public auditing with Merkle tree

  • All the users verify the consistence of timestamp service
  • occasionally retrieves the root
  • the more users, the more secure
  • single timestamp service for all the users
  • Difficult to create double history
  • NDN interest does not carry sender address
  • Interest may not reach timestamp service (satisfied by cache)

31 VTS

A B

From whom?

/TimestampTree/2050/3/0 /TimestampTree/2050/3/0

slide-32
SLIDE 32

Summary

  • After fact validation is an authentication model for non-

instantaneous communication

  • decouple the lifetime of data and signature
  • encourage the use of short-lived key
  • Untrustworthy but verifiable timestamp service in NDN
  • borrow the concept public auditing concept from Certificate

Transparency

  • publishing Merkle-tree as data simplifies verification query

processing

  • absence of source address and efficient data distribution

facilitates public auditing

32

slide-33
SLIDE 33

Outline

33

Automating Data-Centric Authenticity Authenticating Long-Lived Data Automating Data-Centric Confidentiality

slide-34
SLIDE 34

Data confidentiality

  • Current practice: perimeter-based security
  • data stays in trusted container
  • pass data to authorized users through an end-to-end secure

channel

  • Can we support data owner controlled confidentiality

without trusted container and secured end-to-end channel?

34

  • 2. authenticate requester

& apply access control

  • 1. set up secure channel
  • 3. deliver data over secure channel
slide-35
SLIDE 35

Data Producer Data Consumer

Data-centric confidentiality

  • Encrypt data at the time of production
  • Distribute decryption keys to authorized consumers
  • Design challenges
  • How does a producer learn the authorized consumers?
  • changing authorized consumers
  • distributed production
  • How to distribute decryption keys efficiently?

35

Specify privilege using hierarchical name Publish encryption instruction as named keys

slide-36
SLIDE 36

Distributed production & Dynamic sharing

  • Shared album in SmartHome
  • members produce photos at different sites in different years
  • shared with relatives later
  • no pre-knowledge about whom the photos will be shared with
  • House surveillance video
  • produced by cameras in different rooms
  • allow security personel to watch the video when nobody at

home

  • no pre-knowledge when family is out

36 /My/home /My/home/album /My/home/monitor /My/home/album/2014/yosemite /My/home/album/2012/zion /My/home/monitor/backyard /My/home/monitor/frontdoor /My/home/monitor/backyard/2015/5/2/9/0 /My/home/monitor/backyard/2015/5/2/9/1

slide-37
SLIDE 37

Content key

  • Data is encrypted using a content key (C-KEY)
  • symmetric key
  • generated by producer
  • Minimal access granularity
  • encrypt data under the namespace
  • Distributed to authorized consumers eventually

37 /My/home /My/home/album /My/home/monitor /My/home/album/2014/yosemite /My/home/album/2012/zion /My/home/monitor/backyard /My/home/monitor/frontdoor /My/home/monitor/backyard/2015/5/2/9/0 /My/home/monitor/backyard/2015/5/2/9/1 /My/home/album/2012/zion/1 /My/home/album/2012/zion/2 /My/home/album/2012/zion/3 /My/home/album/2012/zion/C-KEY

/[content_namespace]/C-KEY

/My/home/monitor/backyard/2015/5/2/9/C-KEY

slide-38
SLIDE 38

Name: /My/home/album/2012/zion/1/FOR/ My/home/album/2012/zion/C-KEY Content: Signature Bits: 31:4d:a8:... EncryptionInfo: Algorithm: AES Initial Vector: 8c:25:e7:... Encrypted content: b4:75:6f:...

Encrypted data

  • A data packet with encrypted content
  • encryption metadata
  • encrypted content
  • Encryption key name is encoded in data name
  • different keys lead to different copies of encrypted data
  • follow encryption key name,

retrieve decryption key

38

/[content_name]/FOR/[encrypt_key_name]

My/home/album/2012/zion/C-KEY/... Interest:

slide-39
SLIDE 39

Content key distribution

  • Distribute content key as encrypted data
  • encrypted using authorized consumer’s public key
  • producer can publish the encrypted content key later
  • consumer can construct a decryption

chain following the names

39 Name: /My/home/album/2012/zion/C-KEY/ FOR/My/home/relative/diane/KEY Content: Signature Bits: 31:4d:a8:... EncryptionInfo: Algorithm: AES Initial Vector: 8c:25:e7:... Encrypted content: /My/home/album/2012/zion/1 Interest: /My/home/album/2012/zion/1/FOR/My/home/album/2012/zion/C-KEY Data: /My/home/album/2012/zion/C-KEY/FOR/My/home/relative/diane/KEY Data: /My/home/album/2012/zion/C-KEY/ Interest: /My/home/album/2012/zion/C-KEY/FOR/My/home/relative/diane/KEY Interest:

slide-40
SLIDE 40

Access control policy distribution

  • Some producers require updated access control policy
  • surveillance camera
  • Access control policy
  • a list of (namespace, authorized consumer key set)
  • Namespace owner publishes access control policy
  • producer retrieves the latest policy

40 /My/home/monitor/backyard Name: /My/home/READ/monitor/ backyard/2016050209/2016050218 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY /HomeGuard/AliceFamily/KEY

/My/home/READ/monitor/backyard/2016050209/2016050218 policy data prefix access namespace time interval

/My/home/member/alice/KEY /My/home/member/bob/KEY /HomeGuard/AliceFamily/KEY /My/home/READ/monitor/backyard/2016050209 /My/home/READ/monitor/backyard/2016050209/2016050218 /My/home/READ/monitor/backyard/2016050218 /My/home/READ/monitor/backyard/2016050218/2016050309

slide-41
SLIDE 41
  • Policy retrieval overhead
  • large data packet for popular

namespace

  • redundant key retrieval
  • Key encryption overhead
  • a large number of content key
  • an encrypted copy of content key

for each authorized consumer

  • numbers of encrypted copies of

content keys: O(mn)

  • m: number of authorized consumers
  • n: number of content keys

Name: /My/home/READ/monitor/ frontdoor/2016050209/2016050218 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY /HomeGuard/AliceFamily/KEY /Community/Security/KEY /My/home/neighbor/karl/KEY /My/home/neighbor/ellen/KEY

Scalability issues

41 Name: /My/home/READ/monitor/ backyard/2016050209/2016050218 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY /HomeGuard/AliceFamily/KEY Name: /My/home/READ/monitor/ backyard/2016050218/2016050309 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY Name: /My/home/READ/monitor/ backyard/2016050309/2016050318 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY /HomeGuard/AliceFamily/KEY

Does a producer have to know all the authorized consumers?

slide-42
SLIDE 42

Namespace encryption key

  • Namespace owner publish namespace encryption

keys instead of namespace access policy

  • Number of encrypted copies: O(m+n)

42 Name: /My/home/READ/monitor/ backyard/2016050209/2016050218 Content: Signature Bits: ... /My/home/member/alice/KEY /My/home/member/bob/KEY /My/home/member/cathy/KEY /HomeGuard/AliceFamily/KEY namespace key Name: /My/home/READ/monitor/backyard/E-KEY/2016050209/2016050218 Content: Signature Bits: ... Name: /My/home/READ/monitor/backyard/D-KEY/ 2016050209/2016050218/FOR/My/home/member/alice/KEY Content: Signature Bits: ... Name: /My/home/READ/monitor/backyard/D-KEY/ 2016050209/2016050218/FOR/My/home/member/bob/KEY Content: Signature Bits: ... Name: /My/home/READ/monitor/backyard/D-KEY/ 2016050209/2016050218/FOR/My/home/member/cathy/KEY Content: Signature Bits: ... Name: /My/home/READ/monitor/backyard/D-KEY/ 2016050209/2016050218/FOR/HomeGuard/AliceFamily/KEY Content: Signature Bits: ...

retrieved by producers distributed to consumers

slide-43
SLIDE 43

Automate granting access

  • Namespace owner can run a key publishing server to

automate data encryption

  • validate consumer’s access request using trust schema
  • generate namespace decryption key for requesting consumer

43 Key Publish Server Consumer Producer Content Encryption Key Video Data Namespace Encryption Key Namespace Decryption Key Namespace Encryption Key Video Access Request Namespace Decryption Key Content Encryption Key Namespace Encryption Key Namespace Decryption Key Namespace Decryption Key Content Encryption Key Video Data Video Data Content Encryption Key

slide-44
SLIDE 44

Implementation

  • Available in all the NDN platform libraries
  • ndn-group-encrypt:
  • http://github.com/named-data/ndn-group-encrypt/
  • NDN-CCL
  • http://named-data.net/codebase/platform/ndn-ccl/
  • Powers data access control in:
  • NDNfit: health data sharing over NDN
  • EBAMS: building management system over NDN

44

slide-45
SLIDE 45

Summary

  • Data-centric confidentiality is a decryption key

distribution problem

  • control access by publishing encryption/decryption keys
  • Key name specifies access at fine granularity
  • automate data encryption
  • Indirected encryption enables scalable key distribution

45

slide-46
SLIDE 46

Conclusion

  • Data-centric security model enables flexible data

communication model

  • reduced dependency on the data containers and channels
  • Usability is critical to any security solution
  • developers need high-level abstraction
  • automation minimizes developer’s workload
  • Expressive names enables usable security in NDN
  • provide sufficient context and fine granularity for least privilege
  • naming pattern can represent flexible trust models and

automate authentication & encryption

46

slide-47
SLIDE 47

Future work

  • Trust schema bootstrapping
  • Robust timestamp service
  • multiple instances
  • failure recovery
  • Enable name confidentiality

47

slide-48
SLIDE 48

List of publications

  • Journal and conference papers
  • Y. Yu, A. Afanasyev, D. Clark, kc claffy, V. Jacobson, and L. Zhang, “Schematizing Trust in Named

Data Networking,” Proc. of ACM ICN, 2015.

  • A. Afanasyev, Z. Zhu, Y. Yu, L. Wang, and L. Zhang, “The Story of ChronoShare, or How NDN

Brought Distributed Secure File Sharing Back,” in Proc. of IEEE MASS, 2015.

  • Y. Yu, D. Wessels, M. Larson, and L. Zhang, “Check-R: A New Method of Measuring DNSSEC

Validating Resolvers,” in Proc. of IEEE TMA Workshop, 2013.

  • Y. Yu, D. Wessels, M. Larson, and L. Zhang, “Authoritative Name Server Selection of DNS Caching

Resolvers,” in ACM Computer Communication Reviews, 2012.

  • Technical reports
  • W. Shang, Y. Yu, R. Droms, and L. Zhang, “Challenges in IoT Networking via TCP/IP Architecture,”

Technical Report NDN-0038, 2016.

  • V. Lehman, A. Hoque, Y. Yu, L. Wang, B. Zhang, and L. Zhang, “A Secure Link State Routing

Protocol for NDN”, Technical Report NDN-0037, 2016.

  • W. Shang, Y. Yu, T. Liang, B. Zhang, and L. Zhang “NDN-ACE: Access Control for Constrained

Environments over Named Data Networking”, NDN, Technical Report NDN-0036, 2015

  • Y. Yu, A. Afanasyev, and L. Zhang “Name-Based Access Control”, Technical Report NDN-0034,

2015

  • Y. Yu “Public Key Management in Named Data Networking”, Technical Report NDN-0029, 2015
  • Y. Yu, A. Afanasyev, Z. Zhu, and L. Zhang “An Endorsement-based Key Management System for

Decentralized NDN Chat Application”, Technical Report NDN- 0023, 2014

  • Y. Yu, J. Cai, E. Osterweil, and L. Zhang “Measuring the Placement of DNS Servers in Top-Level-

Domain” Technical Report, May. 2011

48

slide-49
SLIDE 49

Special Thanks To Collaborators

49

Lixia Zhang Alexander Afanasyev Van Jacobson Alex Halderman Beichuan Zhang Lan Wang David Clark kc claffy Haitao Zhang Spyridon Mastorakis Qiuhan Ding Prashanth Swami Wentao Shang Zhenkai Zhu

slide-50
SLIDE 50

End

50

slide-51
SLIDE 51

NDN Overview

51

  • Native multicast
  • Interest for the same data can be merged

Consumer Consumer Producer

slide-52
SLIDE 52

Data-centric security & NDN

  • Named Data Networking (NDN)
  • data-centric communication primitives
  • retrieve data by name rather by host
  • NDN enables data-centric security
  • per-packet signature
  • hierarchical naming
  • security context
  • least privilege
  • efficient key distribution

52

slide-53
SLIDE 53

SigLogger Overview

  • Security Context Log
  • record security context over the time
  • trust schema
  • assure only one valid version of context

at any time point

  • secure through publicity
  • Revocation Log
  • record revocation over the time
  • promptly distribute revocation

information to consumers

  • Verifiable Timestamp Service
  • provide existence proof of data (and

keys)

  • untrustworthy but auditable
  • Producer distributes proof bundle with

data

  • timestamp of data
  • intermediate keys
  • timestamp of keys

53 subscribe revocation data Consumer Data Storage Verifiable Timestamp Service (VTS) Security Context Log Revocation Log App Authority submit security context monitor security context retrieve security context Key owner Certificate issuer submit revocation record request timestamp verify timestamp Producer auditing auditing distribute data & proof bundle retrieve data & proof bundle

slide-54
SLIDE 54

Signing-based write access

  • Key name represents capability
  • capable of producing data under a namespace
  • capable of delegating the write access of a sub-namespace to others
  • signing key hierarchy
  • Express write access control policy as trust schema
  • Distribute trust schema as data
  • published by data owner retrieved by consumers

54

/alice/KEY/2 /alice/health/data/KEY/3 /alice/health/data/activity/KEY/10

Activity sensor Alice Pulse sensor

/alice/health/data/activity/step/201605020900 signs signs signs /alice/health/data/medical/pulse/KEY/10 /alice/health/data/medical/pulse/201605020900 signs

Alice Data Owner Interest: /alice/health/Schema Name: /alice/health/Schema/v1 Content: Signature: trust anchor trust rule ... trust anchor trust rule ... Data Consumer Bob

slide-55
SLIDE 55

Append-only timestamp service

  • Chaining timestamp data by hash
  • each timestamp data fixes all the previous timestamp bundle
  • Consistence verification
  • consumer remembers the hash of timestamp bundle at ti
  • consumer retrieve the timestamp bundle for tj (i < j)
  • check whether hj can be computed from hi
  • any modification before ti will be detected

55 t0 t1 t2 t3 t4 t5 /time/t0 /time/t1 /time/t2 /time/t3 /time/t4

hk = H(TBk|hk-1)

t0 t1 t2 t3 t4 t5 /time/t0 null /time/t1 h0 /time/t2 h1 /time/t3 h2 /time/t4 h3 t0 t1 t2 t3 t4 t5 /time/t0 null /time/t1 h0 /time/t2 h'1 /time/t3 h'2 /time/t4 h'3

No way to know whether the timestamp service is honest about [ti,tj)

slide-56
SLIDE 56

Public auditing

  • Easy to catch misbehavior if
  • the consistency of each timestamp bundle is checked by at

least one consumer

  • Each consumer verifies consistence occasionally
  • A lot of consumers collectively audit the single

timestamp service

  • How to minimize verification overhead

56

slide-57
SLIDE 57

Use Case Example

  • Alice obtains a timestamp for her thesis
  • also for keys if not timestampped
  • distribute data with keys and timestamps
  • Bob verifies the existence of keys using timestamp
  • verifies data using keys

57 time /ucla/KEY /ucla/cs/KEY /ucla/cs/alice/KEY /ucla/cs/alice/thesis Validate /ucla/cs/alice/thesis /ucla/cs/alice/KEY expires /ucla/cs/KEY expires /ucla/KEYexpires Verifiable Timestamp Service (VTS)