Intelligent Agents Security

1
Intelligent Agents - Security

• Katia Sycara
• The Robotics Institute
• email katia_at_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 cant 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 gt 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
• ltusegt 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 m2ACA-signed certificate binding
  pub(a) to AID
• 6. Creates an entry Ds public key certificate,
  m1 in the certification DB
• 8. Verify the signature in m2 with ACAs 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 gt make the
  deployer aware of his or her liabilities.

26
Revoking an Agents 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, Tmm

31
Secure Communication Channels

• SSL (Netscapes 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/fo
  rmats.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.