Slide 1Java SecurityOverview of Java Security featuresJava 2 Security ArchitectureByte Code VerifierClass LoadersSlide 7Code SourceSecurity Policy FilesSlide 10Slide 11Slide 12Slide 13Slide 14Slide 15PermissionsPermission SubclassesSocket PermissionPropertyPermissionOther Permission SubClassesPolicy Files for HomeworkSecurity ManagerAccessControllerKeystoreCore SecuritySlide 26Core securitySlide 28Slide 29Slide 30Slide 31Slide 32AuthenticationWeb AuthenticationUnderstanding Login AuthenticationHTTP AuthenticationForm AuthenticationCertificate AuthenticationPassword AuthenticationDigest AuthenticationCryptographic ConceptsMessage DigestProtected Password LoginSlide 44Message Digest PasswordDouble-Strength Password LoginSlide 47SignaturesSlide 49Limitations with SignaturesCertificatesSlide 52Elements of a CertificateJava Cryptography OverviewService ClassesService Classes in JDK1.2Java Cryptography ExtensionCryptographic Service ProvidersEnterprise SolutionsToo many users?J2EE Security classificationsReferences and ResourcesGeorge BlankUniversity LecturerJava SecurityOverview 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.Java 2 Security ArchitectureBootstrap class filesSystem class filesUser classfilesBytecode VerifierBootstrapClassLoaderSystemClassLoaderClassLoaderSecurity Manager Protection DomainsAccessControllerOperating SystemHardwarePermissionsKeystoreCodeSource(URL,Certificates)Policy DatabaseByte Code VerifierChecks 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.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 code’s signers is initially available to the ClassLoader.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.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 codeSecurity 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.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/classesSecurity 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 changedSecurity 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.policy=MyApp.policy MyApp For applets appletviewer –J-Djava.security.policy=MyApplet.policy MyApplet.htmlSecurity 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.policy==MyApp.policy MyApp then your application uses only the specified policy file and standard policy files are ignored.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”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 url’s in windows.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"Permission SubclassesFile permission class.•Gives rights to local files/directories.•Path name/pattern. Specific path:file,directory,directory/file. All files in directory: directory/*. All files recursively in directory: directory/-. For current directory, omit "directory/." For all files (dangerous), "<<All Files>>."•Rights set (1+):