Intelligent Agents - Security - PowerPoint PPT Presentation

About This Presentation
Title:

Intelligent Agents - Security

Description:

Intelligent Agents - Security Katia Sycara The Robotics Institute email: katia_at_cs.cmu.edu www.cs.cmu.edu/~softagents Security for Electronic Commerce Insecure ... – PowerPoint PPT presentation

Number of Views:167
Avg rating:3.0/5.0
Slides: 34
Provided by: onnsh6
Learn more at: http://euro.ecom.cmu.edu
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com