1. Security Through Publicity Eric Osterweil Dan Massey Batsukh Tsendjav Beichuan Zhang Lixia Zhang

2. Motivation • Security threats are a driving force in current protocol design • Public key cryptography is common tool • DNSSEC authenticates DNS messages • Various BGP Security authenticates routing • And many many more….. • Protocols are now established relatively mature • Deployment is essentially non-existent • Everything works if only there was a PKI….

3. Example: DNS Security Caching DNS Server www.darpa.mil Authoritative DNS Servers www.darpa.mil = 192.5.18.195 Plus (RSA) signature by the darpa.mil private key End-user Attacker can not forge this answer without the darpa.mil private key. Our Problem: How Do You Get The Public Key?

4. Public Key Infrastructure • Well known hierarchical PKIs • Ex: Web certificate authorities exist • Protocols propose rigid PKIs • DNSSEC follows DNS tree • Internet routing follows address registration • But This Assumes that • Everyone agrees on the hierarchy • Hierarchy members agree to manage keys

5. DNSSEC Hierarchy

6. DNSSEC Hierarchical PKI • DNSSEC PKI follows the DNS tree hierarchy • Root private key signs edu public key • Edu private key signs ucla.edu public key • Ucla.edu private key signs cs.ucla.edu public key • But this assumes that… • Hierarchy members agree to manage keys • Root, com, edu, etc not motivated to sign until lower level zones sign • Lower level zones get little benefit with PKI via root, com, edu, etc. • Everyone agrees on the hierarchy • Some signatures naturally deviate from tree • Ex: netsec.cs.colostate.edu signs netsec.cs.ucla.edu

7. Webs and Reputations • Web of Trust (PGP) • Small World effect • Trust is not transitive, or explicit • Only addresses keys (no accountability for actions) • No root of trust graph = no stipulated trusted authority • Webs tend to be incomplete • Reputation Systems • Generally create a high-level trust rating • Looks like a credit score • Trust is subjective in large systems • No central authority to set reputation rules • If there was such an authority, we would make it a CA!

8. Our Proposed Solution: PSKI • Predicated on the Public Space and that it is a complete data set of actions • Data guaranteed to be complete, not correct! • Protocols that use the PSKI must perform all actions in the public space • Forcing all data into public view can create problems for incorrect data…. • Beyond the Web of Trust: • Web of Trust does not represent actions • Tracing bad behavior is not possible

9. What About Privacy? • The PSKI is initially designed to work in systems where privacy is not an issue • We feel that the initial protocols that use the PSKI will operate on public data sets (well known data) • Example: DNS Security • No privacy concern in posting zone keys and signatures used to authenticate zone keys.

10. Public Space in DNS • DNSSEC defines it own semantics for storing keys and signing records. • The public space then mandates that these actions must be made public. • PSKI lists all DNSKEYs every reported to belong to the zone • All on-tree signatures and all off-tree signatures • Some PSKI semantics added for storing this • PSKI enforces completeness rule • Resolvers judge trustworthiness

11. PSKI - Components • Entities: • The public key for a zone • May be conflicts (two keys both claim to be ucla.edu) • And its associated actions • Trust Graph: • Graph RRSIG records thatrepresent cross-signed DNSKEYs • Actions: • Cryptographic audit-trail

12. DNSSEC in the PSKI

13. Going Forward • Construct rigorous semantics • Investigate issues surrounding privacy • Grouping Entities • Similar to Zones in DNSSEC • Keys are 1-to-1 with Entities BUT apps like DNSSEC zones are n-to-1

14. Going Forward (2) • Lack of a PKI has been a major barrier for sometime • Current protocols (DNSSEC, secure routing, etc.) are being gated • Can we store complete information? • What kind of abstraction crystallizes zones and signatures?

15. Thank You Questions?

16. Goals • Developing key infrastructures for the Internet • Goals for this key infrastructure • offer a rigorous framework • must scale • must impart some semantics that facilitate trust assessment

17. Backup

18. Observations • Internet-scale key infrastructures do not exist • PKIs seem too rigid for such a scale • Web of trust does not impart enough rigor for trust • New secure protocols need to be built, and need a generic infrastructure

19. PSKI Details - Entities • Key ID • Key • Inception / Expiration

20. PSKI Details - Trust Graph • Entities • Entity cross signatures • Lapses of Entity registration • An Entity is allowed to expire, then renewed later • Rollover information

21. PSKI Details - Actions • Lookup-key • Entity • Action Type • Inception / Expiration • Target of Action

22. PSKI Details - Entities’ Actions • Entities relate to their actions with meta-data: • How often an Entity has signed for data • How many active/unexpired • Links to actions • Current conflicts (with other Entity signatures) • Total number of conflicts for this Entity