1. MET CS 667: 6. Security - Zlateva
Distributed applications are notoriously difficult to implement due to:
the complexity of partitioning the 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  security aspect.
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.
Fall 2003
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 )
Fall 2003
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.
Fall 2003
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.
Fall 2003
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.
Fall 2003
MET CS 667: 6. Security - Zlateva

6. Classes, Protection Domains and Permissions
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.
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.
Fall 2003
MET CS 667: 6. Security - Zlateva

7. MET CS 667: 6. Security - Zlateva
Access Control
Source
my.java
Bytecodes
my.class
compilation
javac
Interpretation (java)
load
verify
execute
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
Fall 2003
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.
Fall 2003
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.
Fall 2003
MET CS 667: 6. Security - Zlateva

10. Security Manager, Security Policy, Permissions
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.
Fall 2003
MET CS 667: 6. Security - Zlateva

11. Code Source, Permissions, and Security Policy
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: any property 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
Security policy
code source
location
certificate
Permission Set 1
permission-a
permission-b …
Permission Set 2
Fall 2003
MET CS 667: 6. Security - Zlateva

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

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

14. 6.1 Basic Security Concepts of Encryption and Authentication
Computer and network security: collection of tools 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.
Fall 2003
MET CS 667: 6. Security - Zlateva

15. Conventional Encryption (also called Symmetric, Single-Key)
algorithm D
decryption
source
message
plain text
secret key X
Y= EK(X)
destination
X = DK(Y)
secure channel
Cryptanalyst X' K'
cipher
(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
Fall 2003
MET CS 667: 6. Security - Zlateva

16. MET CS 667: 6. Security - Zlateva
Cryptanalysis
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 encryption/s
= 7.2 x = years h
= 3.4 x = 5.4 x 1024 years 5.4 x 1018 years
Fall 2003
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
Fall 2003
MET CS 667: 6. Security - Zlateva

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

19. MET CS 667: 6. Security - Zlateva
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.
Fall 2003
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.
Fall 2003
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).
Fall 2003
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 (n)
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) or
e*d  1 mod (n) or
d = e (multiplicative inverse)
Fall 2003
MET CS 667: 6. Security - Zlateva

23. MET CS 667: 6. Security - Zlateva
RSA Algorithm
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}
Encryption:
Plaintext: M
Cipher: C = Me (mod n)
Decryption:
Plaintext: C
Cipher: M = Cd (mod n)
Fall 2003
MET CS 667: 6. Security - Zlateva

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

25. MET CS 667: 6. Security - Zlateva
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
Fall 2003
MET CS 667: 6. Security - Zlateva

26. Conventional Encryption: Confidentiality and Authentication
source a
destination b K
secret key E X
Y= EK(X)
X = DK(Y) D
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)
Fall 2003
MET CS 667: 6. Security - Zlateva

27. Public Key Encryption: ConfidentialityX
KUb E
Y= EKUb(X)
X = DKRb(Y)
source a
destination b
KRb D
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)
Fall 2003
MET CS 667: 6. Security - Zlateva

28. Public Key Encryption or Signature: Authentication
KRa E X
Y= EKRa(X)
M = DKUa(X)
source a
destination b
KUa D
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 )
Fall 2003
MET CS 667: 6. Security - Zlateva

29. Public Key Encryption / Signature: Confidentiality and Authentication
KRa E X
EKRa(X)
source a
destination b
KUa D
KUb
EKUb(EKRa(X))c
KRb
Confidentiality: X encoded at source with KUb and 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)
Fall 2003
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)
Fall 2003
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.
Fall 2003
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
Fall 2003
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
Fall 2003
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.
Fall 2003
MET CS 667: 6. Security - Zlateva

35. 6.2. Cryptography Elements in Java – 6.2.1. Message Digest
The java.security package provides API’s for message digest, digital signature, key management and access lists
Message Digest also called Digital Fingerprint is an authentication mechanism that 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)
Fall 2003
MET CS 667: 6. Security - Zlateva

36. How secure are Message Digests?
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 Not disproved till now.
The values for SHA-1 are 280 and 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.
Fall 2003
MET CS 667: 6. Security - Zlateva

37. MET CS 667: 6. Security - Zlateva
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
MessageDigest class:
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"
Fall 2003
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();
Fall 2003
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
Fall 2003
MET CS 667: 6. Security - Zlateva

40. Digital Signatures – DSA
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 It is a public key method as is RSA. As opposed to the RSA, however, it cannot be used for encryption and key exchange.
Fall 2003
MET CS 667: 6. Security - Zlateva

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

42. Digital Signatures in Java
Java implements DSA , RSA class can be bought from RSA (
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
Fall 2003
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:
The key strength of 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
Fall 2003
MET CS 667: 6. Security - Zlateva

44. Digital Signatures in Java – Generate keys and Sign message
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");
returns subclass of Signature
Fall 2003
MET CS 667: 6. Security - Zlateva

45. Digital Signatures in Java - Sign messsage (continued)
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();
Fall 2003
MET CS 667: 6. Security - Zlateva

46. Digital Signatures in Java – 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);
Fall 2003
MET CS 667: 6. Security - Zlateva

47. MET CS 667: 6. Security - Zlateva
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: , 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
Fall 2003
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)
Fall 2003
MET CS 667: 6. Security - Zlateva

49. MET CS 667: 6. Security - Zlateva
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
(Wal, 1996) James Walsh: True Odds – How Risks Affect Your Everyday Life. Merritt Publishing.
Fall 2003
MET CS 667: 6. Security - Zlateva