1 / 49

Java Security Mechanisms for Distributed Applications

Explore the evolution of Java security from the JDK 1.0 Sandbox Model to fine-grained access control in Java 2, including cryptographic elements and control on interpretation in the JVM.

alicerivas
Download Presentation

Java Security Mechanisms for Distributed Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 6. Security • Distributed applications are notoriously difficult to implement due to: • the complexity of partitioningthe problem into sub-problems and the synchronization of the subtasks problem/algorithm aspect. • The lack of good programming tools – too low-level(e.g. sockets), too complex (e.g. MPI), etc. programming language aspect. • The danger of opening the door to enemy attacks securityaspect. • Although Java successfully addresses programming language concerns by providing an elegant consistent OO syntax, it was its • security model that caused the excitement • when Java was first introduced. • Not a big surprise, really: good syntax is still perceived to be about beauty while security is of immediate practical concern. • Java designers addressed the security aspect from the very beginning and provided a security model as an integral part of the technology not as an afterthought as was the case with other technologies. MET CS 667: 6. Security - Zlateva

  2. Java Security Mechanisms • Language features, such as array bound checking, type checking, disallowing pointer arithmetic. process • Access Control, such as: • checking the integrity of classes when loading them into the JVM; • providing a security manager class to control what actions (down)loaded classes can perform, etc. • Cryptographic Elements: java.security package provides cryptographic algorithms for message digests, digital signatures, key management  enforced by the compilation process (javac) • Control on what goes into the the interpretation process or JVM ( java ) MET CS 667: 6. Security - Zlateva

  3. Java Security Evolution(1) The JDK 1.0 Sandbox Security Model The security model of version 1.0 (known as the sandbox model) was to treat code downloaded from a remote location as untrusworthy and that program can only be run in a restricted environment (the sandbox). (i.g. remote applet was always considered untrusted). Local code was considered trusworthy and was allowed full access to all the system resources. MET CS 667: 6. Security - Zlateva

  4. (2) The Concept of Trusted Code in JDK 1.1 JDK 1.1 offered developers the ability to apply a digital signature to the code they wrote. By looking at the digital signature, the client could decide whether a particular remote code could be trusted or not. If trusted the remote code was treated as local code with full access to all the system resources. If untrusted, the code ran in a restricted environment. MET CS 667: 6. Security - Zlateva

  5. (3) The Fine-Grained Access Control of Java 2 The fine grained access control means the ability to grant specific permissions to a particular piece of code about accessing specific resources of the client. For example, a developer can specify in the policy file that the code can read files in one particular directory and can do nothing else. Java 2 provides better tuning of the access controls then JDK 1.1. MET CS 667: 6. Security - Zlateva

  6. The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. The sandbox utilized in JDK 1.0 is one example of a protection domain with a fixed boundary. A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated by the figure below. Classes, Protection Domains and Permissions The fine-gained and configurable access control of Java 2 security model is built via the use of permissions, policy files, and access controller functionality. You will learn how to implement permissions in a policy file later. MET CS 667: 6. Security - Zlateva

  7. Interpretation (java) Source my.java compilation javac Bytecodes my.class verify load execute Access Control Class Loading: JVM loads classes (from disk or web) as needed (e.g. some class needs subclasses, or system classes) There is a default class loader (over which you do not have control) or you can write your own to replace the default; Bytecode Verification: when the class loader presents bytecodes to JVM the bytecodes are first inspected by a verifier for obviously damaging actions (e.g. uninitialized variables, type mismatch). Security Managers and Permissions: after loading and verification the actions a class object can perform are controlled by the permissions specified in the security manager MET CS 667: 6. Security - Zlateva

  8. Bytecode Verification • Some checks performed by the verifier: • Variables are initialized before used; • Method calls match types of object references; • Private data/method access is not violated; • Local variables are accessed within the runtime stack; • Runtime stack does overflow. • Notes: • Why perform the above checks when a program with such errors will never compile, i.e. a program that has been compiled is safe with respect to the checks performed by the verifier? • Because the bytecode format used by the compiler is well documented and the class bytecodes can be altered after compilation is completed. • According to Godel’s theorem, there is no algorithm that for any given some program can decide whether the program has or has not a given property (e.g. type mismatch, uninitialized variable, stack overflow). • The verifier is no refutation of Godel's theorem: A program accepted by the verifier is always safe, but not vice versa, i.e. not all safe programs are accepted by the verifier as required by the theorem. MET CS 667: 6. Security - Zlateva

  9. Security Managers and Permissions • Checks include whether • A class can access member of another class • Current thread can • accept socket connection from specified host and port number; • open socket connection to specified host and port number; • wait for connection request on specified local port number; • can use IP multicast; • invoke stop, suspend, resume, destroy, setPriority/setMaxPriority, setName, setDaemon of a tread or thread group; • create new class loader; • create new subprocess; • halt the virtual machine; • access specified package; • load dynamic link library • access and modify system properties; • write/delete to specified files. MET CS 667: 6. Security - Zlateva

  10. Goal: Achieve fine grained access for applications • Security Manager: • checks whether a specific action is allowed at run time; • throws security exception if non authorized operation attempted; • Default behavior for: • Applications: no security manager installed– everything allowed; • Applets: appletviewer immediately installs security manager, called AppletSecurity, that is quite restrictive. • To install a specific security manager call static method • setSecurity Manager of System class in main() • or run the program with • java –Djava.security.manager from the command line • The programmer defines what actions are or are not allowed on what classes. • There is only one security manager in any Java program; an attempt to install a second one is successful only if the first security manager allows to be replaced: this is important as some malicious class may want to do away with security. Security Manager, Security Policy, Permissions MET CS 667: 6. Security - Zlateva

  11. Permission Set 1 • permission-a • permission-b … Security policy • code source • location • certificate • code source • location • certificate • Permission Set 2 • permission-a • permission-b … • The ability to formulate different access/permissions for different code sources is implemented through the following concepts and mechanisms: • code source: is characterized by two properties: • location (URL or JAR file), and • certificate – document that identifies where it comes from • permission: anyproperty checked by the security manager Permission classes • security policy: maps code source to permission sets  Policy class • The default Policy object reads permissions from a permission/policy file • protection domain: encapsulates code source and set of permissions for the class •  ProtectionDomain class Code Source, Permissions, and Security Policy MET CS 667: 6. Security - Zlateva

  12. java.security.Permission java.security.AllPermission java.security.BasicPermission java.io.FilePermission java.net.SocketPermission java.io.SerializablePermission java.security.SecurityPermission java.awt.AWTPermission java.lang.RuntimePermission java.nrt.NetPermission java.util.PropertyPermission java.lang.reflect.ReflectPermission Permission class hierarchy (java.security.Permission) MET CS 667: 6. Security - Zlateva

  13. checks reads from Relationship between Access Control Classes SecureClassLoader Policy policy file creates loads Class ProtectionDomain CodeSource URL location Permission Certificate MET CS 667: 6. Security - Zlateva

  14. 6.1 Basic Security Concepts of Encryption and Authentication Computer and network security: collection oftools designed to protect data in nodes of internets as well as their transmission over internet links. Security services: services that enhance security and counter security attacks. Important types of security services: confidentiality: information is accessible only to authorized parties authentication: sender is correctly identified , i.e. the sender is indeed the one he claims to be, and the message has not been altered (sometimes this latter property is separately referred to as integrity) Security mechanisms: detect, prevent, or recover from security attacks. There is a variety of mechanisms providing different (sets of) security services. Practically all of them, however, are based on encryption or encryption-like transformations. Security attacks: actions compromising information security, such as message flow interruption, interception, modification, fabrication. MET CS 667: 6. Security - Zlateva

  15. X' K' Cryptanalyst X Y= EK(X) X = DK(Y) cipher E encryption algorithm K D decryption algorithm source message plain text destination message plain text secure channel secret key Conventional Encryption (also called Symmetric, Single-Key) (Sta, 1999, Figure 2.2. p.23) Typical transformation operations: Substitution: elements (bit, letter, or groups of them) of plain text are mapped to each other and substituted for each other. Transposition: elements of plain text are rearranged. Basic requirement: ability to recover original message without loss of information Most system involve several stages of substitution and transposition and are referred to as product systems MET CS 667: 6. Security - Zlateva

  16. Goal: Find X, K from incomplete information, e.g. cipher text only: encryption algorithm and cipher known known plaintext: encryption algorithm, cipher, another pair plaintext-cipher known; etc. Encryption mechanism is unconditionally secure if cipher text generated does not contain enough information to uniquely determine corresponding plaintext, no matter how much cipher text is available. There is only one encryption algorithm, known as the one-time pad scheme, that is unconditionally secure. computationally secure - cost of breaking cipher exceeds value of encrypted information - time required for breaking exceeds useful lifetime of information Brute force: Key size (b) Alternative Keys 1 encryption/s 106 encryption/s 56 256 = 7.2 x 1016 255 = 1142 years 10.01 h 128 2128 = 3.4 x 1038 2127 = 5.4 x 1024 years 5.4 x 1018 years Cryptanalysis MET CS 667: 6. Security - Zlateva

  17. Example: Conventional Encryption Caesar's Cipher (oldest known): Replace each letter of the alphabet with the one three places further down. Plain: a b c d e f g h i j k l m n o p q r s t u v w x y z Cipher: D E F G H I J K L M N O P Q R S T U V W X Y Z A B C Plain: "I came I saw I conquered" Cipher: L FDPH L VDZ L FRQTXHUHG With letters numbered successively a=1,…, z=26 C = E(letter) = (letter + 3) mod(26) In general : C = E(letter) = (letter + k) mod(26) k= 1,…25 There are 25 possible keys, that allow brute force computation Also: one identified letter, e.g. L=E(i) and the knowledge of the algorithm gives the entire encryption away MET CS 667: 6. Security - Zlateva

  18. X’ KRb’ Cryptanalyst E encryption algorithm Y= EKUb(X) X = DKRb(Y) D decryption algorithm source message plain text cipher destination message plain text KUb KRb public key of destination b private key of destination b key pair source Public Key Encryption (also called Asymmetric, Multiple-Key) source a destination b X (Sta, 1999, Figure 6.2. p.167) MET CS 667: 6. Security - Zlateva

  19. Public Key Encryption • Considered the first truly new idea in cryptography in its 4000 year history. • First publicly introduced by Whitfield Diffie and Martin Hellmand, both of Standford University, in 1975. • Addressed the two most difficult problems of conventional cryptography: • key distribution: conventional encryption requires that both parties have the secret key i.e. they either already have it; or must obtain it through a key distribution center (KDC). Diffie pointed out that distribution centers fail the fundamental requirement of maintaining secrecy over your own communication: • "What good would it do after all to develop impenetrable cryptosystems, if their users were forced to share their keys with a KDC that could be compromised either by burglary or subpoena?" (Diff, 1988) • authentication: electronic messages need the equivalent of a fingerprint or signature to prove they are sent by the party that claims to be sending them. MET CS 667: 6. Security - Zlateva

  20. Some Popular Misconceptions about Public Key Encryption • "Public key encryption is more secure than conventional encryption" • Neither has an advantage over the other. In both methods braking the code depends on length of key and the computational work involved in breaking the cipher. • "Public key encryption has made conventional encryption obsolete" • Not at all, as computational overhead on public key encryption is high. Because of this Diffie states that " the restriction of public-key cryptography to key management and signature applications is almost universally accepted" (Diff,1988) • "Key distribution is trivial when using public key encryption" • Some form of protocol is still needed and sometimes may be not simpler than the ones for conventional cryptography. MET CS 667: 6. Security - Zlateva

  21. The Rivest-Shamir-Adelman Algorithm (RSA ) The first public key encryption algorithm was proposed by Rivest, Shamir and Adelman (RSA) , from MIT, first published in 1978. It processes the plaintext in blocks, and each block is encrypted with a value between 0 and n-1 (mod n). For some plaintext block M the cipher text block C is C = Me mod n For decryption M = Cd mod n = (Me) d mod n i.e. e*d mod (n) = 1 With KU = {e, n} - public key KR = {d, n} - private key Sender knows public key {e, n} , receiver the private key{d, n}. Note that both sender and receiver know the value of n (also public). MET CS 667: 6. Security - Zlateva

  22. The Rivest-Shamir-Adelman Algorithm (RSA ) We want: M = (Me) d mod n Def: Two numbers a,b are relatively prime iff gcd(a,b)=1. Def: Euler totient function (n)= number of positive integers less than n and relatively prime to n, Ex: n 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 (n) 1 1 2 2 4 2 6 4 6 4 10 4 12 6 8 Note: for any primes p, q: (p) = p-1 and (p*q) = (p-1)(q-1) TH:m k (n) +1 = m k (p-1)(q-1) +1 = m mod n Then e*d should be of the form: e*d = k (n) +1 or e*d  1 mod (n) or d = e-1 (multiplicative inverse) MET CS 667: 6. Security - Zlateva

  23. Key Generation: • Select two primes p and q • Calculate n = p*q • Calculate the Euler totient function (n)= number of positive integers less than n and relatively prime to n, (two numbers a,b are relatively prime iff gcd (a,b)=1) (n) = (p-1)(q-1) • Select integer e such that gcd ((n), e ) = 1, 1 < e < (n) • Calculate d = e-1 mod (n) Result:KU = {e, n} KR = {d, n} RSAAlgorithm Encryption: Plaintext: M Cipher: C = Me (mod n) Decryption: Plaintext: C Cipher: M = Cd (mod n) MET CS 667: 6. Security - Zlateva

  24. Example: Key Generation • p=3 , q= 5 primes Encryption: Plaintext: M =2 Cipher: C = Decryption: Plaintext: Cipher: MET CS 667: 6. Security - Zlateva

  25. Authentication Authentication verifies that message is received from the source that claims to have sent it and that the message has not been altered Message Digest, or Fingerprints: hash function: Condenses a block of data of arbitrary length to fixed length (160 bits) sequence Algorithms: MD5 and SHA-1 Digital signatures: Uses public key encryption technique on hash function output Algorithms: RSA or DSA MET CS 667: 6. Security - Zlateva

  26. Y= EK(X) X = DK(Y) X E D K secret key K source a destination b Conventional Encryption: Confidentiality and Authentication Confidentiality no one else knows the secret key K Authentication: correct source: the only other party in position to construct a message is a as only a knows the secret key K no alterations in message: if message recovered no bits have been altered, as opponent does not know K, thus cannot how to alter message (Sta, 1999, Figure 8.1) MET CS 667: 6. Security - Zlateva

  27. source a destination b Y= EKUb(X) X = DKRb(Y) X E D KUb KRb Public Key Encryption: Confidentiality Confidentiality: only b has private key key KRb NO Authentication: * source can be anybody: who gets public key KUb, encrypts and sends Y (Sta, 1999, Figure 8.1) MET CS 667: 6. Security - Zlateva

  28. source a destination b Y= EKRa(X) M = DKUa(X) X E D KRa KUa Public Key Encryption or Signature: Authentication No Confidentiality: anyone can get a’s public key and decipher message. Authentication: correct source: only a has the private key KRa and only a can produce the message no alterations in message: if message recovered no bits have been altered, as only a can produce message (Sta, 1999, Figure 8.1.c ) MET CS 667: 6. Security - Zlateva

  29. source a destination b X EKRa(X) EKUb(EKRa(X))c EKRa(X) X E D E D KRa KUb KRb KUa Public Key Encryption / Signature: Confidentiality and Authentication Confidentiality: X encoded at source with KUband no one else knows the secret key KRb Authentication: correct source: only ‘a’ has the private key KRa and only ‘a’ can produce the message no alterations in message: if message recovered no bits have been altered, as only a can produce message (Sta, 1999, Figure 8.1. d) MET CS 667: 6. Security - Zlateva

  30. 6.2. JAVA Security Architecture Overview Java Authentication and Authorization Service (JAAS) Java Secure Socket Extension (JSSE) Java Cryptography Extension (JCE) Java 2.0 Security Platform Core Java 2.0 Security Architecture Java Cryptography Architecture (JCA) MET CS 667: 6. Security - Zlateva

  31. The Java Authentication and Authorization Service (JAAS) JAAS provides a platform that users are required to have explicit permission in order to perform certain operations. A JAAS-enabled application requires the user to login – a for authentication and authorization purposes. Authentication is done through Kerberos – an open source protocol available from MIT, that uses conventional cryptography to identify users in a network and maintain privacy of communication. At login the permissions specified in the policy file, administrated by the system administrator, are applied to the user. MET CS 667: 6. Security - Zlateva

  32. The Java Cryptography Extension (JCE) JCE provides a variety of cryptographic operations, more specifically: - Encryption (Ciphers)- Secure Key Exchange- Secure Message Digests- Key management system MET CS 667: 6. Security - Zlateva

  33. The Java Secure Sockets Extension (JSSE) • Secure Sockets Layer (SSL) protocol was originally designed by Netscape for use in its browser and secure servers. Currently used by most businesses for secure on-line transactions. SSL protocol provides data encryption over TCP sockets. UDP socket and other forms are not supported. • SSL implements public key technology using RSA and digital certificates to authenticate the server in a transaction; client authentication is not required: many servers consider a valid credit card number sufficient for authentication. • SSL at work: • client sends message to server; • server responds and sends its digital certificate for authentication; • using public key cryptography to communicate client and server negotiate session keys to continue the transaction MET CS 667: 6. Security - Zlateva

  34. The Java Secure Sockets Extension (JSSE) • JSSE integrates SSL encryption in Java technology; it provides • encryption (conventional as well as public key available), • message integrity checks, • authentication of server and client. • JSSE uses • keystore : a location that holds keypairs and certificates used in Public Key Infrastructure (PIK) • truststore : a keystore location that holds certificates used by the receiver to check against the the certificate received from the sender. MET CS 667: 6. Security - Zlateva

  35. The java.security package provides API’s for message digest, digital signature, key management and access lists • Message Digest also called Digital Fingerprint is anauthentication mechanismthat works as follows: • Digest-algorithm: data block  bit sequence • of arbitrary length of fixed length • Properties: • if one or several bits of data change, message digest changes too • forger in possession of a given message cannot construct fake message with same message digest • Algorithms: • MD5 (RFC 1321) by Ron Rivest at MIT • hash-function: X  128-bit sequence (processed in blocks of 512 bits) • SHA1 • hash-function: X  160-bit sequence (processed in blocks of 512 bits) 6.2. Cryptography Elements in Java – 6.2.1. Message Digest MET CS 667: 6. Security - Zlateva

  36. Both algorithms are computationally secure: Rivest conjectures that MD5 is as strong as possible for a 128 bit hash code, i.e. odds that two messages have the same signature is of the order of 264 operations and odds of finding a message with a given digests of the order of 2128. Not disproved till now. The values for SHA-1 are 280 and 2160 respectively. Odds that an original and a forged message have the same SHA1 signature: According to (Wal, 1996): Chances you die being struck from lightening ca 1/30,000. If you choose 9 people of your friends and acquaintances, the chance they and you die from lightening is higher than a forged message having the same fingerprint as the original. (Careful: Chance that any 10 people will die from lightening is practically 1, but you probably know none of them.) MD5 has been lately found vulnerable to cryptographic analysis. The most serious concern was raised by Dobbertin 1996: he proposed an attack technique that operates on a single 512-bit input block and finds another block that produces the same 128 bit output. No generalization of this attack to the full message is yet known. SHA1 appears not to be vulnerable to cryptanalysis attacks. Less known about its design criteria, however. How secure are Message Digests? MET CS 667: 6. Security - Zlateva

  37. class MessageDigest • Java implements MD5 and SHA1.Computing a message digest with either algorithm requires the following steps : • Create objects that encapsulate the message digest algorithms through the • MessageDigestclass: • MessageDigest is • a factory class, and • superclass for all fingerprinting algorithms • An object algMsgD is created through the getInstance method: • MessageDigest algMsgD = MessageDigest . getInstance("SHA-1"); returns MessageDigest object implementing specified algorithm Alternatively "MD5" MET CS 667: 6. Security - Zlateva

  38. class MessageDigest (continued) Feed all message bytes to MessageDigest objects by calling update method until entire message processed FileInputStream in = new FileInputStream(f); int ch; while ((ch = in.read ( ) ) != -1) algMsgD.update ( ( byte ) ch ); Call digest method that pads the input (required by algorithm), performs computation and returns digest as array of bytes byte [] hash = algMsgD . digest(); MET CS 667: 6. Security - Zlateva

  39. 6.2.2. Digital Signatures - RSA • Two approaches to digital signatures: a) RSA and b) DSA • RSA: • at source: • - input message to be signed in hash function to produce secure hash code of fixed length; • - encrypt hash code with sender’s private key; • - transmit (unencrypted) message and signature; • at destination: • - take message and produce hash code; • - decrypt signature with sender’s public key; • - compare signature with produced hash code MET CS 667: 6. Security - Zlateva

  40. b) DSA (Digital Signature Algorithm) presented in the DSS (Digital Signature Standard) by NIST (National Institute of Standards and Technology) at source: - input message to be signed in hash function to produce secure hash code of fixed length; - in a signature function, input hash code, a random number k, sender’s private key (KRa). and parameter set that constitutes a global public key (KUG). The result is a two component (s, r) signature; at destination: - take message and generate hash code; - in verifier input hash code, signature, sender’s public key (KUa), the global public key (KUG ). The verifier outputs component r if signature is valid. DSS was proposed in 1991 revised in 1993 and in minor ways in 1996. It is a public key method as is RSA. As opposed to the RSA, however, it cannot be used for encryption and key exchange. Digital Signatures – DSA MET CS 667: 6. Security - Zlateva

  41. H M M s r M EKRa (H(M)) Compare H E EKRa (H(M)) D KRa KUa M H Ver Compare H Sig KUa KUG k KRa KUG a) RSA RSA vs. DSA b) DSA M Message E Encryption function H Hash function D Decryption function Sig Compute Signature in DSA Ver Verify Signature in DSA MET CS 667: 6. Security - Zlateva

  42. Java implements DSA , RSA class can be bought from RSA (www.rsa.com). • To use DSA one needs to: • Generate a key pair. • Sign a message • Verify signature. • To generate a new random key pair one should use truly random numbers: use SecureRandom class rather than Random class which is not secure; it is better to provide a seed. If seed is not provided a 20 byte seed is computed by launching threads, putting them to sleep and measuring the exact time they are awaken. (HoCo 2000) propose obtaining random input from a hardware device such as a white-noise generator: • SecureRandom secrand = new SecureRandom(); • byte [] b = new byte[20]; • //fill with truly random bits • secrand.setSeed(b); • //passed to the KeyPairGenerator object Digital Signatures in Java MET CS 667: 6. Security - Zlateva

  43. Digital Signatures in Java - class KeyPairGenerator 1. Generate a key pair: - Create KeyPairGenerator object: KeyPairGenerator keyGen = KeyPairGenerator . getInstance (" DSA "); - Initialize KeyPairGenerator object with key strength and a secure number generator: Thekey strengthof the algorithm is not the length of the key but the number of bits of the modulus used in the algorithm keyGen.initialize( 512, secrand); Returns KeyPairGenerator object implementing DSA MET CS 667: 6. Security - Zlateva

  44. Generate key pair • KeyPair keys = keyGen.generateKeyPair(); • //one can generate more than one key pair with the same KeyPair object • KeyPair otherKeys = keyGen.generateKeyPair(); • Each pair has a public and private key that can be obtained as follows: • PublicKey pubKey = keys.getPublic(); • PrivateKey privKey = keys.getPrivate(); • 2. Sign message • Create a Signature object using the Signature factory class that (similarly to the MessageDigest class) is a factory and a superclass of the object it produces. • Signature signAlg = Signature.getInstance("DSA"); Digital Signatures in Java – Generate keys and Sign message returns subclass of Signature MET CS 667: 6. Security - Zlateva

  45. Initialize Signature object. The Signature object can be used both for signing and verification. The choice is made through initialization of the object either with initSign() or initVerify() method. Sign with the private key signAlg.initSign(privKey); Update to process all message while ((ch = in.read()) != -1) signAlg.update((byte) ch); Compute signature byte [] signature = signAlg.sign(); Digital Signatures in Java - Sign messsage (continued) MET CS 667: 6. Security - Zlateva

  46. Digital Signatures in Java – Verify signature 3. Verify signature At recipient site create a Signature object Signature verifyAlg = Signature.getInstance("DSA"); Initialize Signature object for verification: verifyAlg.initVerify(pubKey); Update to process all message while ((ch = in.read()) != -1) verifyAlg.update((byte) ch); Verify signature: boolean chek = verifyAlg.verify(signature); MET CS 667: 6. Security - Zlateva

  47. Trusted Channels and Authentication: Digital Certificates, Public Key Infrastructure (PIK) source trusted friend Certificate Authority (CA) KRs KUs Trusted Channel: KUs KUs in Key File KRCA KUCA class1: e-mail, other info not verified class3: requestor must appear before a notary public, financial record checked sign with KRCA include KUs Trusted Channel: KUCA verify source key with KUCA authenticate message with Kus destination MET CS 667: 6. Security - Zlateva

  48. Digital Certificates Format • One of the most common X.509 widely usde by Verisign, Microsoft, Netscape contains: • Version of certificate format, • Serial number of certificate, • Signature algorithm identifier (algorithm and parameters used), • Name of signer of certificate; • Period of validity • Name of identity being certified, • Public key of identity being certified (algorithm, parameters, public key value), • Signature (hash code of all preceding fields, encoded with private key of signer) MET CS 667: 6. Security - Zlateva

  49. References (Bish 2003) Bishop, M.: Computer Security: Art and Science. Addison Wesley, 2003. (Diff, 1988) Diffie, W.: The First Ten Years of Public-Key Cryptography. Proceedings of the IEEE, May 1988 (Dobb, 1996) Dobbertin, H.: The Status of MD5 After a Recent Attack. Crypto-Bytes, Summer 1966. (HoCo 2000), Ch9, Cay S. Horstmann, Gary Cornell: Core Java 2. Volume 2: Advanced Features. Prentice (Kauf 2002) Kaufman, Charlie; Radia Perlman, Mike Speciner: Network Security: Private Communications in a Public World. 2d ed. Prentice Hall, NJ, 2002. (Sta, 1999) William Stalling: Cryptography and Network Security- Principles and Practice. 2d edition. Prentice Hall. ISBN 0138690170. (Wal, 1996)James Walsh: True Odds – How Risks Affect Your Everyday Life. Merritt Publishing. MET CS 667: 6. Security - Zlateva

More Related