Java Security - PowerPoint PPT Presentation

1 / 62
About This Presentation
Title:

Java Security

Description:

George Blank University Lecturer Java Security Overview of Java Security features Java Technology uses three mechanisms to ensure safety. Language design features ... – PowerPoint PPT presentation

Number of Views:206
Avg rating:3.0/5.0
Slides: 63
Provided by: webNjitE9
Category:
Tags: java | security

less

Transcript and Presenter's Notes

Title: Java Security


1
George Blank University Lecturer
2
Java Security
3
Overview of Java Security features
  • Java Technology uses three mechanisms to ensure
    safety.
  • Language design features(bounds checking on
    arrays,legal type conversions etc).
  • An access control mechanism that controls what
    the code can do(file access, network access etc).
  • Code signing code authors can use standard
    cryptographic algorithms to authenticate java
    programming language code. Users of the code can
    determine who created the code and whether the
    code is altered or not after it was signed.

4
Java 2 Security Architecture
5
Byte Code Verifier
  • Checks a classfile for validity
  • Code should have only valid instructions and
    register use.
  • Code does not overflow/underflow stack.
  • Does not convert data types illegally.
  • Accesses objects correct types.
  • Method calls use correct number and types of
    parameters.
  • References to other classes use legal names.

6
Class Loaders
  • Is an important link in security chain and loads
    java byte codes into the JVM.
  • It works in conjunction with the security manager
    and access controller to enforce security rules.
  • It is involved in enforcing some security
    decisions earlier in an objects lifetime than the
    security manager.
  • Information about the URL from which the code is
    originated and the codes signers is initially
    available to the ClassLoader.

7
Class Loaders
  • Customized ClassLoader or a subclass from
    java.security.SecureClassLoader provides security
    features beyond the standard Java2 security
    model.
  • ClassLoader loads classes into VM and is
    responsible for the namespaces at runtime.
    Namespaces as identically named identifiers can
    reference different objects.
  • Primordial class loader loads bootstrap classes
    in a platform-dependent manner.
  • System classes, some classes in java. package
    are essential to the JVM and the runtime system
    are loaded by System ClassLoader.

8
Code Source
  • Java Code is downloaded over a network, so the
    code's signature and author are critical to
    maintain a secure environment.
  • The object java.security.CodeSource describes a
    piece of code.
  • CodeSource encapsulates the code's origin, which
    is specified as an URL.
  • Set of digital certificates containing public
    keys corresponding to the set of private keys are
    used to sign the code

9
Security Policy Files
  • SecureClassLoader assigns permissions when
    loading classes, by asking policy object to look
    up the permissions for the code source of each
    class.
  • Own Policy class can be installed to carry out
    mapping from code sources to permissions.

10
Security Policy Files
  • Example of a policy file
  • grant codebase www.horstmann.com/classes
  • permission java.io.Filepermission /tmp/ ,
    read, write
  • The above file grants permission to read and
    write files in the /tmp directory to all code
    that was downloaded from
  • www.horstmann.com/classes

11
Security Policy Files
  • Policy files can be installed in standard
    locations and the two default locations are
  • The file java.policy in the java platform home
    directory.
  • The file .java.policy in the user home directory.
  • The locations of these files in the
    java.security configuration files can be changed

12
Security Policy Files
  • During testing standard files are not modified
    and hence policy file is required for each
    application.
  • For this purpose place permissions into a
    separate file such as MyApp.policy and start the
    interpreter as
  • java Djava.security.policyMyApp.policy MyApp
  • For applets
  • appletviewer J-Djava.security.policyMyApplet.po
    licy

  • MyApplet.html

13
Security Policy Files
  • In the previous example MyApp.policy file is
    added to other policies in effect. If you add a
    second equal sign, such as
  • java Djava.security.policyMyApp.policy MyApp
  • then your application uses only the specified
    policy file and standard policy files are ignored.

14
Security Policy Files
  • Policy file contains a sequence of grant entries.
    Each entry has the following form.
  • grant codesource
  • permission_1
  • permission_2
  • ..
  • The code source contains a code base and the
    names of trusted certificate signers.
  • The code base is specified as Codebase url

15
Security Policy Files
  • If the code base url ends with a /, it refers to
    a directory, otherwise it is taken as a JAR file.
  • grant codebase www.horstmann.com/classes/
  • grant codebase www.horstmann.com/classes/MyApp
    .jar
  • The code base is an url and should always contain
    forward slashes as file separators, even for
    urls in windows.

16
Permissions
  • Permission classes represent access to various
    system resources such as files, sockets and so
    on.
  • Collection of permissions can be construed as a
    customizable security policy for an installation.
  • Permission classes represent approvals, but not
    denials.
  • Permissions granted to a ProtectionDomain also
    called "privileges"

17
Permission Subclasses
  • File permission class.
  • Gives rights to local files/directories.
  • Path name/pattern.
  • Specific pathfile,directory,directory/file.
  • All files in directory directory/.
  • All files recursively in directory
    directory/-.
  • For current directory, omit "directory/."
  • For all files (dangerous), "ltltAll Filesgtgt."
  • Rights set (1) read,write,execute,delete.

18
Socket Permission
  • Host.
  • Local Machine "local host."
  • Given machine IP address or hostname.
  • All hosts in a domain .domain.
  • All hosts .
  • Portrange.
  • Single port portnumber.
  • Port range port1-port2, port1-,-port2.
  • Actions(1) accept,connect,listen,resolve.

19
PropertyPermission
  • Gives rights to properties.
  • Similar to OS environment variables.
  • Target.
  • Specific property os.name.
  • Pattern java..
  • Actions (1) read,write.

20
Other Permission SubClasses
  • Runtime Permission string with permission name
  • - createClassLoader
  • - getClassLoader
  • - setSecurityManager
  • - exitVM

21
Policy Files for Homework
  • On your homework assignments, you will want to
    think about permissions for the client and
    server, and make sure you give permissions for
    both the host name or IP address and the port
    number. You may also need access to ports on the
    local host to access utilities like HTTP for an
    applet. Example
  • grant
  • permission java.net.SocketPermission
  • "afs1.njit.edu1950-2000","connect,accept,resolve"
  • permission java.net.SocketPermission
  • "afs1.njit.edu80","connect"

22
Security Manager
  • The class java.lang.SecurityManager is the focal
    point of authorization.
  • SecurityManager is concrete, with a public
    constructor and appropriate checks in place to
    ensure that it can be invoked in an authorized
    manner.
  • It consists of a number of check methods.
  • eg CheckPermission method is used to check to
    see if the requested access has the given
    permission based on policy.

23
AccessController
  • The java.security.AccessController class is
    used for three purposes.
  • To decide whether access to a critical system
    resource should be allowed or denied, based on
    the security policy currently in effect.
  • To mark code as privileged, thus affecting
    subsequent access determinations.
  • To obtain a snapshot of the current calling
    context, so access-control decisions from a
    different context can be made with respect to the
    saved context.

24
Keystore
  • Keystore is a password-protected database that
    holds private keys and certificates.
  • The password is selected at the time of creation.
  • Each database entry can be guarded by its own
    password for extra security.
  • Certificates accepted into the keystore are
    considered to be trusted.

25
Core Security
  • Java 2's security pieces reside primarily in
  • java.lang
  • java.security
  • java.security.cert
  • java.security.interfaces
  • java.security.spec

26
Core Security
  • Java.lang.
  • Contains the SecurityManager class, which allows
    applications to implement a security policy.
  • The SecurityManager determines the operation's
    identity and whether it can be performed in its
    security context.

27
Core security
  • java.lang
  • The manager contains many methods that begin with
    the word check.
  • Eg.
  • SecurityManager security System.getSecurityMa
    nager()    if (security ! null)
            security.checkXXX(argument,  . . .
    )    

28
Core security
  • java.security.
  • Contains most security classes and interfaces.
  • It contains classes for access control,
    parameters for the various cryptographic
    algorithms, code source, guarded objects, key
    management, message digests, permission, policy,
    protection domains, providers, secure class
    loaders, random number generators, and digital
    signatures.
  • The following Java code can be used to produce a
    permission to read files in the /tmp directory.
  • FilePermission p new FilePermission("/tmp/",
    "read")

29
Core Security
  • java.security.
  • Entries in the policy file can also be used
    to achieve similar results. The following is a
    sample entry in the policy file that indicates
    the granularity of providing access.
  • // Sample policy filegrant signedBy
    "signer_names", codeBase "URL"     permission
    permission_class_name "target_name",
    "action",    signedBy "signer_names"    

30
Core Security
  • Many classes provide a Service Provider Interface
    (SPI) for providers to plug in their
    implementations. Examples include MessageDigest,
    Signature, KeyPairGenerator, and so on.
  • The MessageDigest class supports the MD5 and SHA
    algorithms.

31
Core Security
  • The getInstance() method is invoked to select the
    appropriate algorithm.
  • The method update() is called to ready the input
    buffer, while the digest() method generates a
    message digest, the size of which (in this case,
    128 bits, or 16 bytes) depends on the algorithm
    (in this case, MD5).
  • The digest() method would generate 160 bits (20
    bytes) for the digest if the SHA algorithm was
    used.

32
Core Security
  • The java.security.cert package deals with
    certificates. It provides, for instance, an
    abstract class to import, generate, and verify
    X.509 certificates.
  • The java.security.interfaces package is a set of
    interfaces used to generate DSA and RSA key
    pairs.
  • The java.security.spec package may be used to
    control the parameters for various algorithms,
    like DSA or RSA, and their corresponding keys.

33
Authentication
  • Authentication is tremendously important in
    computer applications.
  • The program or person you communicate with may be
    in the next room or on another continent you
    have none of the usual visual or aural clues that
    are helpful in everyday transactions.
  • Public key cryptography offers some powerful
    tools for proving identity.

34
Web Authentication
  • There are several different ways that
    authentication normally occurs on the Internet.
  • The next slide lists five methods, with slides
    following it to describe those methods.

35
Understanding Login Authentication
  • When you try to access a protected web resource,
    the web container activates the authentication
    mechanism that has been configured for that
    resource. You can specify the following
    authentication mechanisms
  • HTTP basic authentication
  • Form-based login authentication
  • Client certificate authentication
  • Mutual authentication
  • Digest authentication

36
HTTP Authentication
  • With basic authentication, the following things
    occur
  • A client requests access to a protected resource.
  • The web server returns a dialog box that requests
    the user name and password.
  • The client submits the user name and password to
    the server.
  • The server validates the credentials and, if
    successful, returns the requested resource.

37
Form Authentication
  • With form-based authentication, the following
    things occur
  • A client requests access to a protected resource.
  • If the client is unauthenticated, the server
    redirects the client to a login page.
  • The client submits the login form to the server.
  • If the login succeeds, the server redirects the
    client to the resource. If the login fails, the
    client is redirected to an error page.

38
Certificate Authentication
  • In certificate-based authentication, the
    following things occur
  • A client requests access to a protected resource.
  • The web server presents its certificate to the
    client.
  • The client verifies the server's certificate.
  • If successful, the client sends its certificate
    to the server.
  • The server verifies the client's credentials.
  • If successful, the server grants access to the
    protected resource requested by the client.

39
Password Authentication
  • In user name- and password-based mutual
    authentication, the following things occur
  • A client requests access to a protected resource.
  • The web server presents its certificate to the
    client.
  • The client verifies the server's certificate.
  • If successful, the client sends its user name and
    password to the server, which verifies the
    client's credentials.
  • If the verification is successful, the server
    grants access to the protected resource requested
    by the client.

40
Digest Authentication
  • Like HTTP basic authentication, HTTP digest
    authentication authenticates a user based on a
    user name and a password. However, the
    authentication is performed by transmitting the
    password in an encrypted form which is much more
    secure than the simple base64 encoding used by
    basic authentication. Digest authentication is
    not currently in widespread use.

41
Cryptographic Concepts
  • Message digests produce a small "fingerprint" of
    a larger set of data.
  • Digital signatures can be used to prove the
    integrity of data.
  • Certificates are used as cryptographically safe
    containers for public keys.

42
Message Digest
  • A message is used to avoid transmitting a
    password in clear text from a client to a server.
  • A message digest takes an arbitrary amount of
    input data and produces a short, digested version
    of the data.
  • Java Cryptography Architecture (JCA) makes it
    easy to use message digests.
  • The java.security.Message Digest class
    encapsulates a cryptographic message digest.

43
Protected Password Login
  • A basic problem in client/server applications is
    that the server wants to know who its clients
    are.
  • The obvious solution is to send the user's name
    and password directly to the server.
  • Most computer networks, are highly susceptible to
    eavesdropping, so this is not a very secure
    solution.
  • To avoid passing a clear text password from
    client to server, we can send a message digest of
    the password instead.

44
Protected Password Login
  • The server can create a message digest of its
    copy of the password. If the two message digests
    are equal, then the client is authenticated.
  • This simple procedure is vulnerable to a replay
    attack.
  • To avoid this problem some session specific
    information like random number and a time stamp
    are added to the message digest.
  • The server can use them to calculate a matching
    digest value.

45
Message Digest Password
46
Double-Strength Password Login
  • This is a stronger method for protecting password
    information using message digests.
  • Why is it Required?
  • A message digest is one way function
  • It takes less time to test a single password
    using dictionary attack
  • A dictionary attack is to try passwords one at a
    time and attempting to login each time
  • It increases the time required for a dictionary
    attack

47
Double-Strength Password Login
48
Signatures
  • A signature provides two security services,
    authentication and integrity.
  • A signature is a message digest that is encrypted
    with the signer's private key.
  • Only the signer's public key can decrypt the
    signature, which provides authentication.
  • If the message digest of the message matches the
    decrypted message digest from the signature, then
    integrity is assured.
  • The Java Security API class, java.security.Signatu
    re represents cryptographic signatures.

49
Signatures
  • The basic procedure is very similar to the
    password based.
  • The client generates a timestamp and a random
    number.
  • The client creates a signature of this data and
    sends it to the server.
  • The server can verify the signature with the
    client's public key.

50
Limitations with Signatures
  • Signatures do not provide confidentiality. A
    signature accompanies a plain text message.
    Anyone can intercept and read the message.
  • Creating and maintaining the public key database
    is difficult.
  • The server needs to obtain these public keys in a
    secure way.
  • Certificates solve this problem.

51
Certificates
  • A certificate is a statement, signed by one
    person, that the public key of another person has
    a particular value.
  • It's like a driver's license.
  • The license is a document issued by your state
    government that matches your face to your name,
    address, and date of birth.
  • Note that the license only has value because you
    and your local shopkeepers trust the authority of
    the state government.
  • Digital certificates have the same property.

52
Certificates
  • Certificate associates an identity with a public
    key.
  • The identity is called the subject.
  • The issuer that signs the certificate is the
    signer.

53
Elements of a Certificate
  • Information about the subject.
  • The subject's public key.
  • Information about the issuer.
  • The issuer's signature of the above information

54
Java Cryptography Overview
  • The Java Cryptography Architecture is split into
    two different packages
  • JDK
  • Java Cryptology Extension
  • Sun had to split the architecture due to US
    export laws which prohibits software encryption
    technology from being released outside of the
    United States or Canada (certain types of
    cryptographic software are considered "weapons"
    by the U.S. government).

55
Service Classes
  • Signature Used to sign and verify digital
    signatures.
  • Message Digest Used to calculate the message
    digest (hash) of specified data.
  • KeyPairGenerator Generate a pair of public and
    private keys suitable for a specific algorithm.
  • KeyFactory Converts cryptographic keys of type
    'key' into key specifications.
  • AlgorithmParameterGenerator Generates
    parameters for a particular algorithm.

56
Service Classes in JDK1.2
  • AlgorithmParameters Manages the parameters for
    a particular algorithm.
  • KeyStore Used to create and manage a key store.
  • SecureRandom Generates pseudo random numbers.

57
Java Cryptography Extension
  • The JCE removes users from the implementation of
    cryptography, and the algorithms involved, making
    both easy to use.
  • A programmer can specify algorithms, or the JCE
    architecture will choose the default algorithms.
  • An application that uses an object that needs a
    specific CSP service or algorithm will run
    through the installed providers, and choose the
    first default provider with an appropriate
    service.
  • Alternately programmers can choose specific
    providers for specific services.

58
Cryptographic Service Providers
  • RSA Data Security Inc.
  • eSec Limited (formally Australian Business Access
    )
  • Forge Research.
  • DSTC
  • Entrust Technologies
  • Cryptix
  • IAIK

59
Enterprise Solutions
  • This has been a rather basic introduction to Java
    Security. When you get to large applications
    with many users, there are additional concerns,
    normally at the level of Web servers and Java 2
    Enterprise Edition.
  • The following slides introduce those concerns.

60
Too many users?
  • Since Web Applications can have large numbers of
    users, it may not be convenient to control
    security at the user level.
  • The following slide shows ways that this
    complexity can be managed.

61
J2EE Security classifications
  • User An individual (or application program)
    identity that has been defined in the Application
    Server. Users can be associated with a group.
  • Group A set of authenticated users, classified
    by common traits, defined in the Application
    Server.
  • Role An abstract name for the permission to
    access a particular set of resources in an
    application. A role can be compared to a key that
    can open a lock. Many people might have a copy of
    the key. The lock doesn't care who you are, only
    that you have the right key.
  • Realm A collection of users and groups that are
    controlled by the same authentication policy.

62
References and Resources
  • Inside Java 2 Platform Security, Li Gong, Addison
    Wesley, 1999.
  • Java Cryptology, Jonathon Knudsen, O'reily and
    Associates, 1998.
  • Java Security Handbook, Jamie Jaworski and Paul
    Perrone, SAMS Publishing, 2000.
Write a Comment
User Comments (0)
About PowerShow.com