Packet Validation in the Network Environments Yingdi Yu UCLA 1 - - PowerPoint PPT Presentation

▶
packet validation in the network environments
SMART_READER_LITE
LIVE PREVIEW

Packet Validation in the Network Environments Yingdi Yu UCLA 1 - - PowerPoint PPT Presentation

Oct 10, 2022 34 likes •228 views

Packet Validation in the Network Environments Yingdi Yu UCLA 1 Packet Authentication How to authenticate a data packet containing the electricity usage of a room at certain time? Data is signed, but how to verify the signature?

slide-1
SLIDE 1

Packet Validation in the Network Environments

Yingdi Yu UCLA

1

slide-2
SLIDE 2

Packet Authentication

  • How to authenticate a data packet

containing the electricity usage of a room at certain time?

  • Data is signed, but how to verify the

signature?

– How to get the signer’s public key? – How to authenticate the signer? – Why the signer should be trusted? – Should the signer be trusted at this moment?

2

slide-3
SLIDE 3

Data & Certificate

  • Retrieved as data packets

– public keys are just another type of content

  • Data packets are similar to certificates

– data is signed

  • Data packets are incomplete certificates

– no signature validity period – no signature revocation information

  • Current solution:

– put validity period & other extensions in content

  • Ideal solution:

– extend SignatureInfo

3 Name: Certificate name MetaInfo: Content: (DER encoded) ValidityPeriod: NotBefore NotAfter PublicKeyInfo: Extensions: SignatureInfo: SignatureType: KeyLocator: SignatureValue: Name: Certificate name MetaInfo: Content: PublicKeyInfo: (Still X509 format) SignatureInfo: SignatureType: KeyLocator: ValidityPeriod: CriticalExtension? NonCriticalExtension? SignatureValue:

slide-4
SLIDE 4

Naming

  • Every data is named, what is the name of certificate?
  • A certificate binds a key to a namespace (identity)

– e.g., /<namespace>/[KeyId]

  • absolute KeyId: globally unqiue, e.g., key hash
  • relative KeyId: uniquely identify a key under the namespace, e.g, SeqNo
  • Application interprets the namespace as some real world

identity

– in BMS, “/bms/boelter/4805/electrical” is interpreted as a sensor in the Room 4805 of Boelter Hall at UCLA – in openHealth, “/ucla/haitao/ndnex/dvu” is interpreted as a health data publisher of a user “/ucla/haitao”

  • Certificate name may include version number

– different signature versions (Key rollover)

4

slide-5
SLIDE 5

Public Key Fetching/Provisioning

  • Express an interest using the cert name in KeyLocator

– certificate name of signer’s public key (w/o version)

  • Certificate is published somewhere

– current solution:

  • published as NDN DNS record

– /ndn/ucla/KEY/yingdi/ksk-123/ID-CERT/%01

  • published through repo

– issue: prefix aggregation

  • demux interest for certificate introduces extra name components

in cert name

– /ndn/KEY/ucla/yingdi/ksk-123/ID-CERT/%01 – /ndn/ucla/yingdi/KEY/ksk-123/ID-CERT/%01

  • General certificate infrastructure? or app-specific

certificate infrastructure?

5

slide-6
SLIDE 6

Signer Authentication

  • Construct a chain of trust

6

/bms/boelter/4805/electrical/ 20150101 /bms/boelter/4805/KEY/dsk-433 /bms/boelter/KEY/dsk-821 /bms/KEY/dsk-376

Policy

The rule to regulate the chain of trust

Trust anchor

The origin of trust

Intermediate Keys

The tool to verify signature

slide-7
SLIDE 7

Validation Framework

Info Manager Trusted Info Unverified Info Policy Checker Authenticator Trust Anchors Certificate Cache Data Buffer Info Fetcher Origin Validation Request Failure Failure Success Auth Info Internal Validation Request Cache certificate Key Retrival Check Signature Failure

7

slide-8
SLIDE 8

Validation Framework

Info Manager Trusted Info Unverified Info Policy Checker Authenticator Trust Anchors Certificate Cache Data Buffer Info Fetcher Origin Validation Request Failure Failure Success Auth Info Internal Validation Request Cache certificate Key Retrival Check Signature Failure

8

slide-9
SLIDE 9

Policy

  • Conditions on the SignatureInfo
  • SignatureType

– some data may require certain type of signature

  • algorithm
  • key size
  • KeyLocator

– some data must be signed by certain parties

  • ValidityPeriod

– signature must be valid at certain timestamp

9

slide-10
SLIDE 10

Policy Rules

  • A rule consists of

– a filter – a set of checkers

  • Filter

– which packet should be checked by the rule

  • Checker

– the conditions that the packet’s SigInfo must meet – could be more than one sets of valid conditions – pass one checker, pass the rule – fail all checkers, fail the policy checking

  • Order of rules matters

– packet will be checked by the first matched rule – rules with more specific filter should go first

10

Filter Checker Checker Rule 1 Filter Checker Rule 2 Filter Checker Rule 3 Filter Checker Checker Rule 4 F F F F F F F P P P P P P

slide-11
SLIDE 11

Policy Language

  • Configurable

– allow apps/users to specify its

  • wn trust models
  • Interpretable

– library can build the validator according to configuration – entities with the same configuration file share the same trust model

  • if router can fetch the policy,

router knows how to validate data

  • Easy to distribute

– can be published as data packet – data name can be fixed with implicit digest

11

rule { filter { packet-type data packet-name <bms><>* } checker { signature-type ecdsa-sha256 min-key-size 256 key-locator { k-pattern (<>*)<KEY>(<>*)<><ID-CERT> \1\2 h-relation is-prefix-of p-pattern (<>*) \1 } } checker { signature-type ecdsa-sha256 min-key-size 256 key-locator { k-pattern (<>*)<KEY>(<>*)<><ID-CERT> \1\2 h-relation is-prefix-of p-pattern <bms>(<>*) \1 } } }

slide-12
SLIDE 12

Multiple signature

  • The same content object may be signed by different keys

– certificates: the same <name, key> pair may be certified by different parties

  • in openHealth, a doctor’s key may be signed by both patient & medical

board of California in order to access the patient’s data

– signature agility: different signing algorithms & key size

  • Introduce a signature extension: OtherSignatureLocator

12

SignatureInfo: ... NonCriticalExtension: OtherSignatureLocator /.../V1/S0 SigValue1 SigInfo1 SigValue2 SigInfo2 /.../V1/Sn SigValue8 SigInfo8 SigValue7 SigInfo7 ...

slide-13
SLIDE 13

Validation Framework

Info Manager Trusted Info Unverified Info Policy Checker Authenticator Trust Anchors Certificate Cache Data Buffer Info Fetcher Origin Validation Request Failure Failure Success Auth Info Internal Validation Request Cache certificate Key Retrival Check Signature Failure

13

slide-14
SLIDE 14

Public key retrieval issues

  • Slow start

– retrieve keys one-by-one, multiple RTTs – may involve more data

  • multiple signatures
  • Single point failure

– validation fail if one key is missing

  • limited internet access
  • key provision failure
  • Key Bundle: why not ask data provider to collect keys

and publish them along with the data?

– fate sharing

  • if data can be fetched, so do the keys

– efficiency

  • if producer collect the keys once, it can benefit many verifiers

14

slide-15
SLIDE 15

Key Bundle Requirements

  • Publisher & consumer agree on the trust policy and trust

anchor

  • In BMS

– single trust anchor – hierarchical policy

  • While expressing interest for data, also

expressing interests for proofs

15 /bms/boelter/4805/electrical/ 20150101 /bms/boelter/4805/KEY/dsk-433 /bms/boelter/KEY/dsk-821 /bms/KEY/dsk-376 /bms/boelter/4805/eletrical/20150201 /bms/boelter/4805/eletrical/20150201/AUTH_INFO/ hierarchy/3d4c89ef.. /bms/boelter/KEY/dsk-821 /bms/boelter/4805/KEY/dsk-433 For data For proof

slide-16
SLIDE 16

Validation Framework

Info Manager Trusted Info Unverified Info Policy Checker Authenticator Trust Anchors Certificate Cache Data Buffer Info Fetcher Origin Validation Request Failure Failure Success Auth Info Internal Validation Request Cache certificate Key Retrival Check Signature Failure

16

slide-17
SLIDE 17

Signature Verification

  • Start when reaching an

pre-authenticated key

  • Check signature status

– should be done after the signature is verified – ensure the signature has not been revoked yet

  • Once an intermediate

signing key is validated

– verify the signature of depending packets – recursively go back to the

  • riginal data packet

17

D0: Original Data Success Failure K1: Signing Key of D0 Success Failure K2: Signing Key of K1 Success Failure K3: Signing Key of K2 Success Failure Pre-authenticate key Build validation path Propagate validation result

slide-18
SLIDE 18

Signature status checking

  • Check if the signature has been revoked before expiration
  • Verifier may retrieve signature status data

– /<DataName>/[DataDigest]/[Timestamp] – content:

  • signature status: good, revoked
  • reasons (optional): revocation reasons
  • Introduce a signature extension StatusChecking

– ForwardingHint: where to forward the signature status interest – AuthorizedSigner: who can be trusted for signing signature status data

18

SignatureInfo: ... (Non)CriticalExtension: StatusChecking: ForwardingHint AuthorizedSigner

slide-19
SLIDE 19

Thanks!

19