Intelligent Agents - Security

1. Intelligent Agents - Security Katia Sycara The Robotics Institute email: katia@cs.cmu.edu www.cs.cmu.edu/~softagents

2. Security for Electronic Commerce

3. Insecure Internet • The original Internet was designed for research, not as a commercial environment. • The TCP/IP protocol suite used by all computers connected to the Internet is fundamentally lacking in security services.

4. Internet Security Weaknesses - 1 • Confidentiality: • Most lower layer protocols, including Ethernet, are “broadcast” in nature: machines connected to a LAN can eavesdrop on each other; • Nodes lying on the path between two communicating parties can “eavesdrop” on traffic as it passes; • Theft of account information, credit card numbers; theft of information-based products; • Other info on “who talked to whom” (even without knowing the content involved) leads to loss of privacy;

5. Internet Security Weaknesses - 2 • Authentication: • Virtually impossible to accurately determine whether the addresses in data packets are genuine or not; • Hosts and users can spoof (impersonate) each other; • Integrity: • Packet contents: no service provided to authenticate the content of packets; • Ex: modification of payee of a check; the value of a check.

6. Internet Security Weaknesses - 3 • Repudiation: • parties may deny having participated in transaction, sent messages, given authorization, etc.; • Hosts need to be protected as well; attacks targeted to retrieve cleartext information from poorly protected systems;

7. Security Requirements for Commercial Transactions • Confidentiality; • Authentication; • Data Integrity; • Non-repudiation; Security mechanisms based on cryptography

8. Some Existing Solutions

9. Cryptographic Building Blocks - 1 • Symmetric key cryptography: • Two parties share a common secret or key; • Keys are used to encrypt and decrypt messages; Can be used for authentication with the help of a third party.

10. Cryptographic Building Blocks - 2 • Public-key cryptographic: • Matching private and public keys: • Can be used to sign and verify signatures:

11. Public Key Infrastructure • Ability to match specific keys with their owners: • Public key certificates (Bind public keys to specific entities and allow for a third party to validate the binding); • Ex: x509 certificate. Can be used for encryption and decryption alone

12. The Risks of Electronic Commerce - 1 • The customers’ perspective: • Stolen payment credentials + passwords; • Dishonest merchants; • Disputes over service qualities; • Dishonest financial service providers; • Inappropriate use of transaction details. • The merchants’ perspective: • Forged or copied instruments; • Disputed charges; • Insufficient funds in customer accounts; • Unauthorized redistribution of purchase items; • Dishonest financial service providers;

13. Not Everything has a Technical Solution • There are problems where solutions can’t be enforced in advance, but where accepted practices solve the problem if followed: • privacy protection; • intellectual property rights; • quality of service. • These practices will usually be followed if: • They are easy to follow; • Social and legal enforcements.

14. Other Weak Points • Hardware; • Operating systems; • System configuration; • System management; • Compilers; • Poorly written software; • Application-level access control; • User neglect

15. Adding Security to Retsina

16. Why do we need to worry about security? • We want to deploy our system in open networks; • Agents come and go => agents interact with strangers; • Can agents be trusted? Can their deployers be trusted? • Agents are expected to do more serious things. Ex: • Getting info on your banking account; • Carry out sales transactions.

17. Assumptions we make • Neither agents nor their deployers are trustworthy (They can misbehave): • Agents may eavesdrop on communication between two other agents; • An agent may masquerade as some other agent; • Agents may not behave as expected (e.g., an agent may not want to pay for goods received). • There must be a few, selected entities that can be trusted.

18. Adding Security to Retsina (MAS in general) • Prevent misbehaviors from happening + have recovery mechanisms if they happen: • Identify different security issues that MAS face; • Propose solutions for these problems; • Design and implement a security infra-structure for Retsina. • Focus: application-independent issues: • Communication security: yes; • Fair exchange in electronic sales: no. • Approach: Standard security techniques used in distributed systems • Authentication; • Access control; • etc.

19. Security Threats in MAS • System-level threats: Those that subvert inter-agent interactions, independently of the application a system is running. • Untrustworthy ANSs and matchmakers; • Untrustworthy application agents; • Insecure communication channels. • Application-level threats: Those that subvert the security of applications. They may exist even if the underlying system of agents is secure. • Service providers that do not implement appropriate access control policies; • Untrustworthy application agents.

20. Our Solution (1) • To guarantee the integrity of naming and matchmaking services: • Include access control: • <use> trusted ANSs and matchmakers! • Make agents uniquely identifiable, and give them unforgeable proofs of identity: • Prevents spoofing; • Make deployers of agents liable for the actions of their agents: • Agents are given proofs of identity only when deployers allow their own identities to be linked with those of their agents.

21. Our Solution (2) • Protect communication channels; • Add access control mechanisms (which usually rely on the delegators’ Ids); • Make agents prove that they are delegates of whom they claim to be.

22. A Design of a Security Infra-structure for Retsina Assumptions: • Deployers have public key certificates binding their physical identities (SSN, company names, etc.) to their public keys; • DCAs are assumed to exist (lie outside our security infra-structure); • ANSs and matchmakers • are trusted entities; • their public keys are publicly known. • The addresses of ANSs are publicly known.

23. Public Key Cryptography • Key pairs: • Private keys: a ; • Public keys: A ; pub(a) • Digital signatures: (m)a • Signature verification: • Use A to verify (m)a • Public key certificates: • (Name, Public key)ca

24. Giving Identities to Agents + Establishing Liability (1) 1. Choose an Agent ID AID 2. Generate a public key pair {a, pub(a)} 3. m1=(certify AID,pub(a),t)d 4. Verify the validity of the request 5. Generate m2=ACA-signed certificate binding pub(a) to AID 6. Creates an entry [D’s public key certificate, m1] in the certification DB 8. Verify the signature in m2 with ACA’s public key.

25. Giving Identities to Agents + Establishing Liability (2) • Agents are given: • a public key certificate, and • a matching private key. • The certification process: • certification can be requested only by deployers who can prove their own identities => make the deployer aware of his or her liabilities.

26. Revoking an Agent’s Public Key

27. Registering at an ANS

28. Unregistering at an ANS

29. The Lookup Protocol Agents are identified by their keys, and not their names!!

30. Matchmaker Protocols • Very similar to ANS protocols; • Differences: • Physical addr may not be shared by more than one agent; capabilities may; • Agents use ANSname.Agentname to register with the matchmaker; • The lookup protocol: 1. CAP 2. [CAP, {[ANS-x1.AID1,CERT1],… [ANS-xn.AIDn, CERTn]}, T]mm

31. Secure Communication Channels • SSL (Netscape’s Secure Socket Layer protocol); • Why? • Keep communication security transparent from the application; • Off-the-shelf trustworthy technology (extensible too). • Implementation: • Local effort: at the Communicator.

32. Secure Delegation + Access Control • Knowing who is the delegator may be necessary or desirable; • Original design: Have the agent know the secret key of its deployers; • Weaknesses: • Agents should not know such important secrets; • Sometimes they do not even have to know (ex: PIN); • Should have a “weaker,” “temporary” solution.

33. Some Interesting Pages • http://microsoft.com/security/tech/certificates/formats.asp • Some introductory material on standards for cryptographic object; • http://security.dstc.edu.au/projects/java/release3.html • Info on a real-world security package (can download the code and play); • Communications of the ACM - June 1996, volume 39, Number 6 • An issue dedicated to EC; from which the article is extracted.