Full HTML for

Basic foilset Remarks on Internet and Java Security

Given by Geoffrey Fox, Mehmet Sen at Basic Information Track Computational Science Course CPS616 on Spring Semester 1999. Foils prepared May 19 99
Outside Index Summary of Material

General Issues
Review of Java Security Mechanisms
"Gossip": Examples of Security problems of various sorts from malicious to annoying
Cryptography: including RSA Public Keys
Authentication and Digital Certificates
Java/JavaScript and Security
Implications for Commerce (the SET system)
Web Servers and Secure Sockets SSL
Some relevant technologies including Kerberos, S/MIME, Clipper, PEM and PGP

Table of Contents for full HTML of Remarks on Internet and Java Security

 Denote Foils where Image Critical
Denote Foils where Image has important information
Denote Foils where HTML is sufficient
1 Remarks on Internet and Java Security Spring 99
2 Abstract of CPS616 Java and Internet Security Presentation
3 Some Reference Material
4 Some General Issues I
5 Some General Issues II
6 Need for Security in Commerce - I
7 Need for Security in Commerce - II
8 Structure of Internet and Security-I
9 Structure of Internet and Security-II
10 Structure of Internet and Security-III
11 A PKZIP Anecdote
12 Downloading Software is Dangerous?
13 The Moldavia Pornographic Phone Scam
14 An Early Netscape DNS Bug
15 Tempest and Control Zones
16 Military Security Levels
17 Firewalls and Gateways - I
18 Firewalls and Gateways II
19 Encrypted Tunnels
20 The Great Clipper Controversy
21 Export Restrictions on Cryptography
22 Denial of Service versus "Attacks"
23 Combining Denial of Service with more Malicious Attack
24 Comments on Denial of Service
25 Some Attacking Concepts
26 Naïve way Viruses Spread themselves
27 Introduction to Cryptography
28 Breaking an Encryption Scheme
29 Types of Cryptographic Function
30 Security Uses of Cryptography
31 Secret Key Cryptography
32 Uses of Secret Key Cryptography
33 Secret Key Authentication
34 Message Integrity with Secret Key Cryptography
35 Public Key Cryptography
36 Insecure Link Transmission with Public Key Cryptography
37 Authentication with public key Cryptography
38 Digital Signatures and Public Key Cryptography
39 Use of Digital Signatures with public key Cryptography
40 Hash and Message Digests
41 Some Math Behind Secret Key Cryptography
42 Some Math behind RSA Algorithm -I
43 Some Math behind RSA Algorithm -II
44 Certificate Authorities
45 Review of Certificate Process
46 Sample Certificate from Netscape
47 VeriSign Digital ID's or Certificates - I
48 VeriSign Digital ID's or Certificates - II
49 VeriSign's Description of Digital ID's
50 VeriSign's Description of Certificate Revocation I
51 VeriSign's Description of Certificate Revocation II
52 The Java Security Model
53 Sandbox mechanism
54 What can applets do - I?
55 What can applets do - II?
56 What can applets do - III?
57 The Byte Code Verifier
58 Byte Code Verification
59 Why is type checking important!
60 Applet Class Loader
61 Going beyond the Sandbox: History of Java Security Models
62 Going beyond the Sandbox-2
63 Going beyond the Sandbox-3
64 JDK 1.2 Security Model
65 JAVA Fine-grained Access Control-1
66 JAVA Fine-grained Access Control-2
67 JAVA Fine-grained Access Control-3
68 JAVA Fine-grained Access Control-4
69 JAVA Fine-grained Access Control-5
70 JAVA Fine-grained Access Control-6
71 JAVA Fine-grained Access Control-7
72 Java Security-Related Tools
73 How to sign Java Code
74 Signing Classes with the Netscape Object Signing Tool
75 Netscape Object Signing Tool -2
76 Netscape Object Signing Tool -3
77 Signing Java Applets with Microsoft's Authenticode
78 Microsoft's Authenticode 2
79 Signing Code with Sun's JDK 1.1.x
80 Signing Code with Sun's JDK 1.1.x-2
81 Signing Code with Sun's JDK 1.1.x-3
82 Browsing Signed Applets
83 The Java Authentication Framework
84 The Java Authentication Framework-2
85 Signing Code with Sun's Java 2
86 Signing Code with Sun's Java 2-II
87 Signing Code with Sun's Java 2-III
88 Signing Code with Sun's Java 2-IV
89 Some Comparisons of Sign Tools
90 Some Comparisons of Sign Tools - 2
91 Secure Electronic Transaction SET
92 Electronic Shopping Experience - I
93 Electronic Shopping Experience - II
94 Features of SET - I
95 Features of SET - II
96 SET Encryption Summary
97 Sample SET Cryptography Use
98 Sample SET Cryptography Steps 2 to 5
99 Sample SET Cryptography Step 6
100 Sample SET Cryptography Steps 7-10
101 Structure of Public Key System in SET
102 Features of Public Key System in SET - I
103 Features of Public Key System in SET - II
104 Cardholder Registration Process in SET
105 Merchant Registration Process in SET
106 Purchase Request Process in SET
107 Payment Authorization and Capture Processes in SET
108 SSL and S/MIME
109 SSL from Netscape I
110 SSL from Netscape II
111 SSL from Netscape III
112 Netscape's Description of S/MIME
113 Generating Certificates on Unix-1
114 Generating Certificates on Unix-2
115 Sample Certificate and primary Key
116 Secure Server Example-NPAC Grading System-1
117 Secure Server Example-NPAC Grading System-2
118 Secure Server Example-NPAC Grading System-3
119 Secure Server Example-NPAC Grading System-4
120 Java Security Manager
121 Java Security Package
122 Java Digital Signatures-1
123 Java Digital Signatures-2
124 Some Other Security Systems
125 KERBEROS
126 KERBEROS - 2
127 SESAME Security System
128 Details on SESAME I
129 Details on SESAME II
130 The GSS-API Security Interface
131 Globus System Security Policy and Requirements -- Overview
132 Further Properties of Globus Entities
133 Globus Application Requirements
134 Relevant Components of Globus
135 Issues in the Globus Security Model
136 Elements of Globus Security Policy I
137 Elements of Globus Security Policy II
138 Globus Security Functional Requirements - I
139 Globus Security Functional Requirements - II
140 JavaScript Security Model
141 JavaScript Security Issues
142 Same Origin Policy
143 Signed Script Policy-1
144 Signed Script Policy-2
145 Signed Script Policy-3
146 Codebase Principals-1
147 Codebase Principals-2
148 Scripts Signed by Different Principals
149 Principals of Windows and Layers
150 Determining Container Principals
151 Identifying Signed Scripts
152 Using Expanded Privileges
153 Targets
154 Targets-2
155 Importing and Exporting Functions
156 Weaknesses in the JavaScript Model
157 Signing Scripts
158 Signing Scripts-2
159 Signing Scripts-3
160 Signing Scripts-4

Outside Index Summary of Material

HTML version of Basic Foils prepared May 19 99

Foil 1 Remarks on Internet and Java Security Spring 99

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Geoffrey Fox
assisted by Mehmet Sen
Syracuse University
NPAC
111 College Place Syracuse NY 13244 4100
3154432163
HTML version of Basic Foils prepared May 19 99

Foil 2 Abstract of CPS616 Java and Internet Security Presentation

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
General Issues
Review of Java Security Mechanisms
"Gossip": Examples of Security problems of various sorts from malicious to annoying
Cryptography: including RSA Public Keys
Authentication and Digital Certificates
Java/JavaScript and Security
Implications for Commerce (the SET system)
Web Servers and Secure Sockets SSL
Some relevant technologies including Kerberos, S/MIME, Clipper, PEM and PGP
HTML version of Basic Foils prepared May 19 99

Foil 3 Some Reference Material

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Web Security and Commerce, Simon Garfinkel and Gene Spafford, Prentice Hall June 1997
  • Lengthy and rather qualitative discussion that covers most important issues
Network Security: Private Communication in a Public World, Kaufman, Perlman and Speciner, Prentice Hall 1995
  • fine discussion of underlying technologies but as "old" misses some key web concepts
Java Security: Hostile Applets, Holes and Antidotes, McGraw and Felten, Wiley 1997
  • focuses on Java with a rather secretive qualitative discussion
See references at http://www.sis.port.ac.uk/~mab/Computing-FrameWork/list.html including:
HTML version of Basic Foils prepared May 19 99

Foil 4 Some General Issues I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Security Privacy Confidentiality and even Inconvenience are similar effects addressed by technologies we will discuss
Why is there so much excitement about the (lack of necessary) security in Java?
In fact Java is one of the few languages where both the language design (e.g. no pointers) and runtime (e.g. byte code verifier) explicitly address security as a major concern.
Java's great contribution was adding programmability to clients but this allows the "bad guys" to program various bad things such as viruses!
HTML version of Basic Foils prepared May 19 99

Foil 5 Some General Issues II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Java does have a very reasonable security model but it does not (did not) come with a complete implementation and so success of its security depends on additional capabilities.
  • Such as Server-Browser implementation of connections
  • The necessary extra stuff was (and is now to some extent) incomplete and had flaws (bugs in the software)
  • Authentication of creator of Java Applet
The Internet is particularly fragile as one mistake/successful "terrorist attack" can impact computers over the whole world
  • The previous highways (interstate roadways) could only be attacked at isolated points (unless one used nuclear weapons) and so required less stringent security concerns
HTML version of Basic Foils prepared May 19 99

Foil 6 Need for Security in Commerce - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Suppose we are buying something from information from an Internet Web Site
Many of the hazards (security risks) are similar to those in mail or postal shopping with sometimes enhancement due to world wide nature of "attacks" and the ease with which digital (as opposed to analogue phones) information can be eavesdropped reliably.
Credit Card number
Info
Ordered Item comes by traditional mechanisms
HTML version of Basic Foils prepared May 19 99

Foil 7 Need for Security in Commerce - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
There is the usual fraud opportunities at both client and server side (fake customer or fake store) and these are already present in non Internet version
  • Security can reduce level of fraud and make this a viable business model
There is the possibility that merchant is attracting customers to site so that it can download applets and other Internet chicanery which can do bad things -- at least invade privacy
There is the possibility that credit card number is snooped and this is directly countered using encrypted transmission
Note we do not need a perfect system and commerce today builds in a certain fraction of loss due to fraud, bankruptcy etc.
HTML version of Basic Foils prepared May 19 99

Foil 8 Structure of Internet and Security-I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Information travels from server to client and back and one needs to discuss server,client and their connection.
  • Secure the server: here one needs to be worried about preserving confidentiality of data (different for different parts of information) and privileges/capabilities of CGI scripts
  • Scripting capability of Perl can be exploited in unwise CGI programs
  • User could input string "I am Geoffrey" or more deviously something like "I am";rm -r *;print "Pretty Evil" and the hidden program can delete files if the Perl CGI script unwisely applied eval(input string)!
  • A slightly more complex input can be dangerous with other Perl commands -- this can be circumvented by testing input for special characters
HTML version of Basic Foils prepared May 19 99

Foil 9 Structure of Internet and Security-II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
We need to secure information while it is travelling back and forth from server to client
  • If both server and client are in an institution, we can hope that network linking them is "secure" i.e. that data travelling back and forth cannot be diverted or eavesdropped by the bad guys.
  • Generally this is not a safe assumption and one needs to encrypt the data and provide authentication so that data cannot be read and you know where it comes from
  • Even in a corporation, one often has islands of relatively secure networks linked by insecure links such as the Internet
  • Technologies such as SSL (Secure socket Layer) implement encryption of messages between server and client
HTML version of Basic Foils prepared May 19 99

Foil 10 Structure of Internet and Security-III

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Finally we need to secure the client. Here Java is particularly important as it (and JavaScript) are the dominant downloaded programs
Note clients are typically single user PC's with NO security and so particularly vulnerable to attack.
Key difficulty is a bad guy developing a program that when downloaded does something you don't want
In real world, we don't invite arbitrary people into our house -- rather we ask for credentials or believe by context (they are an adult accompanying your child's friend) that they are safe
So we need both security in Java to check that code is what it purports to be and steps to establish confidence that what one is downloading is likely to be safe
HTML version of Basic Foils prepared May 19 99

Foil 11 A PKZIP Anecdote

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
In 1995 and 1996, a program called PKZIP30.EXE was placed on many Internet software libraries. This purported to be 3.0 beta release of the well known file compression program PKZIP
Unfortunately, downloading this program, caused ones disk to be erased ......
This is equivalent to a crook turning up at your door in a fake Niagara Mohawk (or what have you) van. In real world, if we are careful, we ask to see credentials of purported service person.
In Web security, one needs digital signatures to establish the credentials of a particular program -- in particular one would expect that PKZIP30.EXE be digitally signed by PKWare the company that created PKZip
Certification Authorities supply "Software Publisher's Certificates" from "certification authorities" who presumably verify credentials of the organizations that they are certifying
HTML version of Basic Foils prepared May 19 99

Foil 12 Downloading Software is Dangerous?

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
So Java applets are actually safer than downloading C C++ or Java Applications as applets cannot access the local disk (unless there is an implementation bug!)
However Applets are so much easier to download as they happen automatically when the HTML page containing them is accessed. Thus they need much stronger security
Note that one typically assumes that downloading from a site such as Netscape MIT or Microsoft is safe but this can be spoofed due to internet routing!
Note that plug-ins are such C/C++/Java code and subject to security difficulties
  • A Macromedia Shockwave plug-in had a bug that allowed one to use it to read information on client computer and so violate (at least) confidentiality
Correct!
Rogue Site substitutes Evil Program
HTML version of Basic Foils prepared May 19 99

Foil 13 The Moldavia Pornographic Phone Scam

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The site sexygirls.com promised subscribers free pornography and all you had to do was to download the customized viewer.
The "viewer" on being downloaded, turned off the modem's speaker, disconnected you from the Internet and redialed to Moldavia. Then you did get the promised pornography but also a huge phone bill for international calls (presumably many dollars per minute)
Moldavian phone company, the sexygirls website and the American phone split the proceeds of these bills!
This is a "security hole" that exists today in phone system outside the internet
HTML version of Basic Foils prepared May 19 99

Foil 14 An Early Netscape DNS Bug

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Many of the famous Java security problems are in some sense "just bugs" and everything in society has bugs from car safety through conventional policing
  • Again Java bugs are more worrisome because they are potentially so widespread
Currently Java is restricted to establishing a network connection to site you downloaded it from. This assumes you trust site and wouldn't connect to iwanttodestroy.yoursystem.org.
So in a Netscape2.0 bug, it was possible to set up applet so that it could connect to an arbitary site
  • Bug involved a malicious DNS server returning a set of IP addresses including allowed and disallowed ones. Netscape2.0 allowed one to connect to disallowed address
  • Now we have established a connection which could break through a firewall and in principle do arbitary damage/breach of confidentiality
Netscape2.01 corrected bug by only allowing connection to original IP address
HTML version of Basic Foils prepared May 19 99

Foil 15 Tempest and Control Zones

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This refers to electronic eavesdropping and most information about this is classified
Large classified computer centers are surrounded by a (earthed) conducting box so it all electronic signals are trapped inside
Of course NSA (National Security Agency) tries to protect nation's security by exploiting inter alia ability to intercept and understand communication between unfriendly folks
One classifies systems by their control zone which measures distance from device up to which one can detect signals
  • One wants a small control zone
Internet and phone system rely on principle of mass confusion. There are so many messages that it is impossible to detect the sensitive ones!
HTML version of Basic Foils prepared May 19 99

Foil 16 Military Security Levels

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
DoD classifies information into 4 levels unclassified < confidential < secret < top secret
These classifications are applied to information in particular areas such as GUNS MIDDLEEAST etc.
Documents are labeled by secrecy level and area
Individuals and programs are given clearances such as (SECRET,{WEBTECH,HPCC})
A human can only run a process with a security rating equal or below that of human
A process can only read information marked with a security level equal to or below that of process
A process can only write information information with a security level equal to or above that of process.
HTML version of Basic Foils prepared May 19 99

Foil 17 Firewalls and Gateways - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
A firewall is a computer that sits between an institutional network and the potentially dangerous insecure Internet/Outside network.
Firewalls can be taught to filter information by address or by content
  • e.g. it could only allow inside-->outside messaging or messages to or from certain sites (this can be fooled by forging network addresses)
  • e.g. it can prevent file transfer but accept email
  • However email is actually a common file transfer mechanism and postscript (for instance) can easily hide rogue programs
  • Often firewalls are highly inconvenient and in mysterious ways handicap legitimate traffic when in fact nobody realizes firewall exists!
HTML version of Basic Foils prepared May 19 99

Foil 18 Firewalls and Gateways II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Now we place a special computer (the gateway) which acts as a functional intermediary between secure IntraNet and Insecure InterNet
Files are transferred back and forth by being deposited on Gateway. Gateway has security difficulties but it only has ephemeral information and can be compromised without serious implications
Firewall Computer I
Corporate
IntraNet
Global InterNet
Firewall Computer II
Gateway Computer
HTML version of Basic Foils prepared May 19 99

Foil 19 Encrypted Tunnels

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
These are used to communicate between two or more secure IntraNets
as opposed to previous discussions which was for Secure <--> Insecure communication
This is a standard security problem addressed by using certificates to identify secure sites; no special action internal to IntraNet and use encryption over the insecure tunnel between two secure havens
Corporate
IntraNet I
HTML version of Basic Foils prepared May 19 99

Foil 20 The Great Clipper Controversy

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Unfortunately once we have set up digital security, the government will be severely handicapped in monitoring communication between sundry bad guys!
They proposed that this be addressed by
  • a)Using a particular (and quite reasonable) encryption technology built into special hardware -- the clipper chip
  • b)The decryption keys used in each chip would be deposited with the government so that they and only they could break any encoding
  • c)The decryption key would actually be shared by two agencies "preventing" abuse by any one high-handed part of government
  • Note mainly aimed at phones and faxes but must address computer networking given growth in internet
Highly controversial as clearly attacks various deeply held principles of free speech
I am more or less certain that it is doomed anyway as too hard in today's world to enforce such a standard
HTML version of Basic Foils prepared May 19 99

Foil 21 Export Restrictions on Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The US government has established restrictions on the "quality" of encryption software that can be exported
This actually translates into general restrictions on security quality as vendors do not want two types of software -- one domestic and one foreign!
Note one can break "low quality" encryption e.g. RSA155 (best technology using 512 binary bits) would take 10,000 PC's a few months to break
  • However the bad guys might to do this to break into Fort Knox but wouldn't bother for your credit card number!
Sun ingeniously released latest software using cryptography produced entirely outside the USA and so again the government is attempting something that is bound to fail!
HTML version of Basic Foils prepared May 19 99

Foil 22 Denial of Service versus "Attacks"

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
There are two broad classes of "security" problems
  • 1) Deliberate attacks - NPAC suffered this 2 years ago when a hacker used a trapdoor to login into a Sun machine and remove all the files on three computers. For Java, these are called "attack applets" by Felten.
  • 2)Denial of Service: these include internet activities that stop desired use of your computers by hogging resources, invading your privacy or just annoying you! These are called malicious applets by Felten
    • NPAC suffered denial of service when a flood of unwanted "junk" email from forged addresses caused some of our servers to go down
    • I get annoyed when I or my children get unwanted email advertising pornographic sites
    • This is the basis of the recent "Melissa" virus
HTML version of Basic Foils prepared May 19 99

Foil 23 Combining Denial of Service with more Malicious Attack

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
So a common strategy is to create a "denial of service" diversion
  • As NPAC has noted, you set up an agent which floods main enterprise Web Server with requests
  • Web Server grinds to a halt and all system people go to look at it and bring it up
In the confusion, you mount a malicious attack -- perhaps on a different machine -- using well known bugs in UNIX ........
HTML version of Basic Foils prepared May 19 99

Foil 24 Comments on Denial of Service

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Examples of accidental denial of service include:
  • Mistakes in included JavaScript which cause infinite loops which can only be addressed by rebooting computer
  • One of my friends had a bug in his email script which sent 50 copies of his message
  • Use of too many graphics in your web pages uses all available network resources!
  • In November of 1996, an HTML page containing 100 tables within a table caused client computers to crash!
Clearly such inconveniences are inevitable and can consequences can only be addressed by careful programming and robust operating systems which will reduce impact.
  • make certain all your key open files are "saved" before accessing unknown pages so that crashs do not destroy information!
HTML version of Basic Foils prepared May 19 99

Foil 25 Some Attacking Concepts

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Virus: A set of instructions that when executed inset themselves into other programs and presumably intend bad consequences.
Bacterium: A free standing program that replicates itself and causes harm by consuming resources
Worm: Similar to a bacterium that propagates over a network
Trapdoor: an undocumented entry point which is written into a program often for debugging purposes
  • A virus can install trapdoors as it propagates
Trojan horse: Instructions hidden in a seemingly useful program which can or do perform bad things. Viruses add Trojan horses to originally good programs
Logic bomb: malicious instructions that trigger on some particular event or time in the future
HTML version of Basic Foils prepared May 19 99

Foil 26 Naïve way Viruses Spread themselves

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Take any good program (for which virus has write privileges) and take instruction at location L1.
Replace this by a jump to L2.
Insert the dreadful code at location L2 followed by original code at location L1. Worry about saving and restoring registers while doing this.
Insert a jump to location L1+1 at end of bad code.
Net result is a program that does all the old program did plus whatever else bad is inserted
This naïve approach can be detected by presence of distinctive byte codes formed by code at L2 or more precisely by checking that a particular program has unexpected length or modify time.
The hacker who entered NPAC installed a trapdoor into UNIX command ps in a way that left length of ps unchanged!
First entered NPAC by "sniffing" somebody's password and using UNIX bugs to get root permissions.
HTML version of Basic Foils prepared May 19 99

Foil 27 Introduction to Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This is old technology first attributed to Julius Caesar who used the nifty cipher which replaced every letter with that three letters further in the alphabet
  • So A becomes D and Z becomes C (using cyclic wraparound)
Most ciphers involve an algorithm and a parameter (this is 3 in the above) where usually algorithm can be public but parameter is kept secret and is called a key
  • key needs to be quite big to be safe (say at least 40 bits long)
  • It is usually not possible to keep algorithm secret and in fact making it public can encourage experts to examine and comment on its reliability (i.e. ease of breaking)
HTML version of Basic Foils prepared May 19 99

Foil 28 Breaking an Encryption Scheme

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
It would be easy to break Caesar's cipher but in general it is hard and in fact exponentially hard as breaking cipher involves some sort of combinatorial (exhaustive) search combined with clever ideas
  • such as looking for common English words such as the
Note that encoding/decoding can be computationally expensive but much less so than code breaking
  • So as computers get faster, the code breaker's job gets easier for FIXED coding strategy but much harder for a coding strategy that takes a fixed time
Methods exist for three scenarios
  • You only have ciphertext gotten by eavesdropping insecure link
  • You have some matched (ciphertext,plaintext) combinations and wish to find plaintext corresponding to some new ciphertext
  • You have ability to get ciphertext for any plaintext of your (the code breaker's) choice
HTML version of Basic Foils prepared May 19 99

Foil 29 Types of Cryptographic Function

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
There are three major types of cryptographic function which differ in functionality and performance
Secret Key Cryptography is what we are most familiar with and has medium performance and functionality. It has one secret key
Public Key Cryptography is a remarkable idea with some very important and non-intuitive capabilities. It is computationally intense and requires some infrastructure to implement. It involves one secret (called private) and one public key known to everybody.
  • Based on computational infeasibility of factoring large numbers which can be found by multiplying two primes
Hash functions (or one way transformations) involve zero keys and encrypt in a way that cannot be decrypted. It is very fast
Methods are combined to produce hybrid approaches that combine necessary speed and functionality
HTML version of Basic Foils prepared May 19 99

Foil 30 Security Uses of Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
1)Transmitting over insecure channels
2)Storage on insecure media (essentially the same ideas as 1) but applied to a different need)
3)Authentication of computers or people at end of a message transmission. This includes digital signatures and password hashing
4)Integrity check that message delivered was the one sent (this is different from ensuring that nobody read information which is 1)). This is called message integrity
HTML version of Basic Foils prepared May 19 99

Foil 31 Secret Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This involves a single secret key and standards are DES (Digital Encryption Standard) and IDEA (International Data Encryption Algorithm)
Commercial systems (used in SSL) are RC2 RC4 RC5
  • Note 40 bit RC2 takes a 64 MIP computer one year to break
HTML version of Basic Foils prepared May 19 99

Foil 32 Uses of Secret Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
There is the natural use for either transmission over an insecure network or for storage on an insecure media.
Strong Authentication implies that one can prove knowledge of a secret (key) without revealing the key and in particular without sending key between two individuals
This is effective authentication but requires as many secrets as pairs of people who need to communicate.
Public key version will only require one key for each individual wishing to be authenticated with anybody else and so is more practical for widespread deployment. N keys and not N2 as for secret key authentication.
Secret key authentication is however faster and much easier to implement for any sets of sites that wish to establish authenticated communication with a shared secret.
HTML version of Basic Foils prepared May 19 99

Foil 33 Secret Key Authentication

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Each individual A and B picks a random number rA and rB which are only known to themselves and a fresh for session to be authenticated. There is shared key KAB which is not to be transmitted but A needs to know that B knows KAB and B needs to know that A knows KAB. The random numbers are known as challenges.
rA
Decrypt xA and see it gives rA
Encrypt rA to give xA
xA
rB
Encrypt rB to give xB
xB
Decrypt xB and see it gives rB
HTML version of Basic Foils prepared May 19 99

Foil 34 Message Integrity with Secret Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Checksums are well known and can be gotten by dividing message into 32 bit groups and anding these groups together.
  • This is designed for fault tolerance and ensures that data was not garbled in transmission
  • hashes (designed properly) cannot be inverted and represent a unique fingerprint of original message.
A secret checksum combines this process with a secret key and produces a MIC (message integrity code) which can be decoded and checked
This can be used with either a ciphertext or plaintext message and guarantees that information is stored or transmitted faithfully
Note encrypting a message does not guarantee that it is not changed!
MIC with plaintext is used by bank electronic fund transfer
HTML version of Basic Foils prepared May 19 99

Foil 35 Public Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This is much younger than other approaches and was first published in 1975. As we have discussed this has key feature of only needing one key per individual/organization requiring encrypted authenticated messaging
It has nontrivial infrastructure to distribute the N public keys for N organizations but this is better than N2 keys for secret key cryptography
Roughly the public key is a very large number that is the product of two primes. The private key is (related to) one of these primes.
It is used differently in two cases
  • Transmission over insecure network where one encodes with public key of receiver (and receiver decodes with their private key)
  • Authentication where you encode signature with private key and check the signature with public key
HTML version of Basic Foils prepared May 19 99

Foil 36 Insecure Link Transmission with Public Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Suppose A has (public key,private key) <eA,dA> and B keys <eB,dB>
A transmits a message mA to B encrypting it with B's public key eB
B decrypts this message and reads it using private key dB
Similarly B sends a message mB to A encrypting with eA which A decrypts with private key dA
Plaintext
Encryption
Public Key
Private Key
HTML version of Basic Foils prepared May 19 99

Foil 37 Authentication with public key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Here A chooses a challenge -- a random number r and can verify that B is at other end using solely public information!
Alice is A
Bob is B
HTML version of Basic Foils prepared May 19 99

Foil 38 Digital Signatures and Public Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Digital Signatures reverse the use of public and private keys
You encrypt with the private and decrypt with the public key
Plaintext
Verification
Plaintext
Signing
Private Key
Public Key
HTML version of Basic Foils prepared May 19 99

Foil 39 Use of Digital Signatures with public key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Here B starts with a document that it is required to prove only could come from B
This could be a piece of software that we wish to know comes from a reputable source
We combine software with a "certificate" (a statement that B is Bob) and either encrypt this with dB or more normally encrypt a message digest (that depends on both message and signature) with dB
This use of a message digest is done for performance as it is time consuming to use public key encryption on full message
Note this signature cannot be forged either by A or any other person pretending to be B.
  • In secret key version A shares B's secret key and can forge messages that purport to be from B
HTML version of Basic Foils prepared May 19 99

Foil 40 Hash and Message Digests

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Given a message m, the hash h(m) must satisfy
  • It can be calculated relatively quickly
  • Given h(m), it cannot be be inverted (to find m) by any practical method
  • Even though many m's will be transformed to the same h(m), this will in practice never happen and it is impossible in practice to find two m's that give the same h(m)
As hash function is known, the security of a hash comes from the unknown message.
  • Messages can be made unknown by concatenating plaintext with a secret key before applying h(m)
These are called one-way transformations as hashes cannot be inverted
  • Practical methods involve a strange combination of anding and permutations which ensures the cryptography safety of method
Message Digests (such as MD2 MD4 MD5 -- MD is Message Digest with 128 bit output -- or SHS -- Secure Hash Standard with 160 bit output output) are used in Public key Systems to reduce computational complexity of encryption (see previous foil)
HTML version of Basic Foils prepared May 19 99

Foil 41 Some Math Behind Secret Key Cryptography

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Secret Key algorithms are based on elaborating a simple idea
Caesar rotated alphabet in his cipher. An obvious extension of this is use a 1<-ɭ permutation of a group of N bits
for DES N=64 and permutation is calculated from a 48 bit key
To make decoding harder, this is done 16 times with different keys extracted from an original 56 bit secret
  • Note secrets in real world are usually generated randomly
This strategy is combined with (ad-hoc) transformations to further obfuscate the process
The full message must be divided into blocks before this and the method of running secret key cryptography on long messages is non trivial (but not very fundamental) as doing in 64 bit separate units would allow information to be freely shuffled!
HTML version of Basic Foils prepared May 19 99

Foil 42 Some Math behind RSA Algorithm -I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
RSA stands for inventors: Rivest Shamir and Adleman
Take a number n = p * q where p and q are primes
Choose a "suitable" number e
Public key is <e,n> and basic encryption algorithm takes message m to be encrypted and forms
  • c = me mod(n)
Decryption involves private key d which is found so that
  • d * e = 1 mod((p-1)(q-1))
Then m = cd mod(n)
As factorization is computationally infeasible (for n of 512 bits in length or more), this encryption cannot be broken.
HTML version of Basic Foils prepared May 19 99

Foil 43 Some Math behind RSA Algorithm -II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
n,c,d are 512 bits; p,q are 256 bits; e could be small (3 or 65537); m must be less than or equal to bit length of n
lengths are doubled in recent implementations
As encoding is time consuming, we only use RSA for small messages anyway. However as in secret key methods, one must in general break longer messages into smaller sizes
  • Deployed schemes use secret key methods (with key exchanged using public key method) for large amounts of data
PKCS (Public Key Encryption Standard) is a standard from RSA for encoding the information to be signed or encrypted through RSA. It incorporates "know-how" to make RSA work reliably.
Diffie-Hellman, El Gamal and DSS (Digital Signature Standard) are RSA like approaches aimed at digital signatures
HTML version of Basic Foils prepared May 19 99

Foil 44 Certificate Authorities

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Certificates are essential for using asymmetric public-private keys
RSA set up VeriSign company which offers web certificates for individuals, servers and software publishers
There are many other authorities
See http://digitalid.verisign.com/info_ctr.htm for a good description of certificates both in general and for Verisign services (http://www.verisign.com)
Individual certificates are for use in Web browsers and for secure web mail(S/MIME) such as that offered by Netscape
There is no agreed format for certificates but X.509 v3 certificate is common (PEM extends this)
HTML version of Basic Foils prepared May 19 99

Foil 45 Review of Certificate Process

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
HTML version of Basic Foils prepared May 19 99

Foil 46 Sample Certificate from Netscape

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
http://home.netscape.com/newsref/ref/netscape-test-ca.html
HTML version of Basic Foils prepared May 19 99

Foil 47 VeriSign Digital ID's or Certificates - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
VeriSign provides issuing, revocation, and status services for four types of Digital IDs --
  • Secure Server Digital IDs,
  • Digital IDs for software publishers,
  • Personal Digital IDs for use with Web Browsers, and
  • Personal Digital IDs for use with S/MIME applications.
VeriSign Digital IDs for servers enable web servers to operate in a secure mode.
  • A VeriSign Digital ID unambiguously identifies and authenticates your server and encrypts any information passed between the server and a web browser.
HTML version of Basic Foils prepared May 19 99

Foil 48 VeriSign Digital ID's or Certificates - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
VeriSign software Digital IDs are used in conjunction with Microsoft Authenticode Technology (software validation) provide customers with the information and assurance they need when downloading software from the Internet.
Personal Digital IDs used by individuals when they exchange messages with other users or online services.
VeriSign offers four classes of personal Digital IDs. The classes are differentiated by their assurance level--the level of confidence that can be placed in the Digital ID based on knowledge of the process used to verify the owner's identity. The identification requirements are greater for higher numbered classes-
  • Class 1 Digital ID offers minimal assurance of the owner's identity,
  • while a Class 4 Digital ID offers assurance of not only the individual's identity, but also of that person's relationship to the specified company or organization.
HTML version of Basic Foils prepared May 19 99

Foil 49 VeriSign's Description of Digital ID's

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
A Digital ID typically contains the:
  • Owner's public key
  • Owner's name
  • Expiration date of the public key
  • Name of the issuer (the CA that issued the Digital ID)
  • Serial number of the Digital ID
  • Digital signature of the issuer
The most widely accepted format for Digital IDs is defined by the CCITT X.509 international standard; thus certificates can be read or written by any application complying with X.509.
  • Further refinements are found in the PKCS standards and the PEM standard.
HTML version of Basic Foils prepared May 19 99

Foil 50 VeriSign's Description of Certificate Revocation I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
A Certificate Revocation List (CRL) is a list of Digital IDs that have been revoked before their scheduled expiration date.
There are several reasons why a key might need to be revoked and placed on a CRL.
  • A key might have been compromised.
  • A key might be used professionally by an individual for a company; for example, the official name associated with a key might be "Alice Avery, Vice President, NPAC."
  • If Alice were fired, her company would not want her to be able to sign messages with that key and therefore the company would place the key on the CRL.
HTML version of Basic Foils prepared May 19 99

Foil 51 VeriSign's Description of Certificate Revocation II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
When verifying a signature, you can check the relevant CRL to make sure the signer's key has not been revoked if the signed document is important enough to justify the time it takes to perform this check.
Certification Authorities (CAs) maintained CRLs and provide information about revoked keys originally certified by the CA.
  • CRLs only list current keys, since expired keys should not be accepted in any case; when a revoked key is past its original expiration date it is removed from the CRL.
  • Although CRLs are maintained in a distributed manner, there may be central repositories for CRLs, that is, sites on networks containing the latest CRLs from many organizations.
  • An institution like a bank might want an in-house CRL repository to make CRL searches feasible on every transaction.
HTML version of Basic Foils prepared May 19 99

Foil 52 The Java Security Model

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Three mechanisms in Java help ensure safety:
Language design features (bound checking on arrays, legal type conversions only, no pointer arithmetic, etc.)
Java "sandbox" mechanism that controls what the code can do (like local file accesses) Common to both Java 1.0 and Java 1.1.
Code signing: Programmers can use standard cryptographic algorithms to embed a "certificate into a Java class. Then, the users can precisely understand who implemented the code and signed. If one alters the code, he would not be able to sign it with the original signature. Users may decide to use or not to use the code depending on the trust of the signer.
HTML version of Basic Foils prepared May 19 99

Foil 53 Sandbox mechanism

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This addresses security of the client machine once an applet has been downloaded and includes processing of security mechanisms such as authentication certificates
There are three parts of the Java Security model:
  • Byte Code Verifier: checks that the downloaded .class files obey the rules of the Java Virtual Machine
  • Class Loader: makes certain that Java classes have a security structure that prevents outside applets contaminating built in runtime.
  • Security Manager: implements overall policy which depends on particular browser and includes privileges open to applets and processing of authentication mechanisms
  • Note first two parts can have bugs; last part can have both bugs and ill advised policies!
HTML version of Basic Foils prepared May 19 99

Foil 54 What can applets do - I?

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Currently the rules are strict and in fact unreasonably so because these rules stop applets from doing things that we want general client programs to do. They are necessary as we must assume the worst about applet!
  • We need security so that we can identify those applets that can be given more privileges!
Applets cannot read write delete rename files
Applets cannot create a client directory or list a directory
Applets cannot find out any information about a client file including whether or not it exists
Applets can only create a connection to computer from which it was downloaded
Applets cannot accept or listen to network connections on any client port
HTML version of Basic Foils prepared May 19 99

Foil 55 What can applets do - II?

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Applets can only create top level windows which carry message "untrusted window". This helps protect one making operating system look alike windows which innocently request you type password or similar information
  • e.g. suppose I wrote an applet that generated window saying "network connection broken" and put up identical window to internet login process. Most people would type in password without thinking!
Applets cannot obtain user's username or home directory name.
Applets cannot define system properties
Applets cannot run any program on the client system using Runtime.exec().
HTML version of Basic Foils prepared May 19 99

Foil 56 What can applets do - III?

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Applets cannot make the interpreter exit through either System.exit() or Runtime.exit() methods.
Applets cannot load dynamic libraries on the client using load() or loadlibrary() methods of the Runtime or System classes
Applets cannot create or manipulate any thread that is not part of same ThreadGroup as the applet.
Applet cannot create a ClassLoader or SecurityManager
Applet cannot specify network control functions including ContentHandlerFactory, SocketImplFactory or URLStreamHandlerFactory
Applet cannot define classes that are part of built in client side packages
HTML version of Basic Foils prepared May 19 99

Foil 57 The Byte Code Verifier

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This check ensures that code to be executed does not violate various semantic rules of the Language and its runtime
In particular check that pointers are legal, access restrictions obeyed and types correct
a .class file consists of some overall information including a magic number, versioning information, a constant pool, information about the class itself (name, superclass etc.), information about fields and methods with the byte codes themselves, debugging information.
The byte codes are essentially machine language for an idealized stack based machine which are translated into true machine code
  • Note such stack based machines are not necessarily best for optimized performance. Compilers use rather different intermediate representation
HTML version of Basic Foils prepared May 19 99

Foil 58 Byte Code Verification

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
First one checks that .class file has correct format
Checks all that can be done without looking at byte codes
  • this includes superclass checking, verification of constant pool, and legal names and types for field and method references, final classes cannot be subclassed or overwritten
Then one looks at the byte code and checks that as executed it will give finite size stacks, correct typing for registers, fields and methods
One does not download the byte codes of required classes. However one does check that the class is used consistently with its definition
Some steps are for run time efficiency such as checking for some run time exceptions can be done at verification stage and removed in running code.
HTML version of Basic Foils prepared May 19 99

Foil 59 Why is type checking important!

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
If one has either deliberately or accidentally a "wild object pointer" that should be to a user defined on/off object but has somehow been applied to a sensitive object.
Then turning userobject.onoff to true is uncontroversial but this applied to appletprivilege could turn on the ability to write files!
  • Note setting userobject.onoff = true is really "go to location of this object and set its start address plus so many bytes to value true"!
Thus normal computer programs often overwrite themselves when you screw-up with a software error.
Java applets can obviously have software bugs but such errors do not let them ever overwrite themselves or anybody else.
  • Otherwise the overwriting can radically change security
Thus Java must guarantee types of objects precisely so operations can be stupid but never violate security.
HTML version of Basic Foils prepared May 19 99

Foil 60 Applet Class Loader

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This second part of Java security implements a policy as to which classes can access which others!
Java classes are divided into groups which have strict access control. There are different (class) name spaces defined by different Class Loader instances and in particular different run in different name spaces and can NOT interfere with each other.
Classes from same source (defined by directory and host machine) are stored in same name space. An Applet can access those classes in its name space as well the built in local classes. It can access classes from other sites if it explicitly specifies a URL and the methods are public.
Note one searches the local classes first or else one could override the built-in classes and so do things like file I/O.
HTML version of Basic Foils prepared May 19 99

Foil 61 Going beyond the Sandbox: History of Java Security Models

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The Original Security Model known as sandbox model used as JDK 1.0.2 Security Model
Sandbox protects access to all system resources Application developers have to write their own SecurityManager to open up the sandbox.
HTML version of Basic Foils prepared May 19 99

Foil 62 Going beyond the Sandbox-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
JDK1.1.x presented the signed applet concept additional to sandbox mechanism.
Code signing provides additional levels of security when downloading remote code:
  • Authentication
  • Integrity
Everything on CLASSPATH is trusted
HTML version of Basic Foils prepared May 19 99

Foil 63 Going beyond the Sandbox-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Finally, JDK 1.2 introduced fine-grained access control mechanism
Easily configurable security policy
Easily extensible access control structure
Extension of security checks to all Java programs, including applets.
HTML version of Basic Foils prepared May 19 99

Foil 64 JDK 1.2 Security Model

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Among some features the followings are included
The least-privilege principle by automatically intersecting the sets of permissions granted to protection domains.
Underlying platform independent security features.
Does not override the protection mechanisms of the underlying operating system
The Java Cryptography Extension (JCE) extends the JDK to include APIs for encryption, key exchange, and message authentication code (MAC). Together the JCE and the cryptography aspects of the JDK provide a complete, platform-independent cryptography API.
JDK 1.2 Software includes
  • Certificate support (X.509 v1,2,3)
  • Support for Secure Socket Layer (SSL) v3.0
  • Code-signing support (keytool, jarsigner) and Policy Tool to define security policy.
HTML version of Basic Foils prepared May 19 99

Foil 65 JAVA Fine-grained Access Control-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Essential mechanisms include the following:
Identity:Every piece of code needs a specific identity for security decisions. Origin (URL) and signature, represented in the class java.security.CodeSource , define identity.
Permissions: System requests to perform a particular operation on particular target are allowed based on permissions. A policy says which permissions are granted to which principals. Permissions include:
  • java.io.FilePermission for file system access, e.g., f = new filePermission ("/tmp/applets.db", "read");
  • java.net.SocketPermission for network access, e.g., sp= new SocketPermission("npac.syr.edu:3768", "connect")
  • java.lang.PropertyPermission for Java properties
  • java.lang.RuntimePermission for access to runtime system resources
  • java.security.NetPermission for authentication
  • java.awt.AWTPermission for access to graphical resources such as windows
HTML version of Basic Foils prepared May 19 99

Foil 66 JAVA Fine-grained Access Control-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Implies: All permissions must implement the implies method "a implies b" means that if one is granted permission "a", then one is also granted permission "b" Permission p1 = new FilePermission("/tmp/*", "read"); Permission p2 = new FilePermission("/tmp/readme", "read"); p1.implies(p2) == true p2.implies(p1) == false Policy: is a mapping from identity to a set of access permissions granted to the code. An example policy object ; grant CodeBase "http://www.npac.com/users/gcf", SignedBy "*" { permission java.io.FilePermission "read,write", "/tmp/applets/*"; permission java.net.SocketPermission "connect", "*.npac.com"; };
HTML version of Basic Foils prepared May 19 99

Foil 67 JAVA Fine-grained Access Control-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Policies can be defined by a user or a system administrators. It is always possible to use a particular policy for selected applications, e.g., appletviewer -Djava.policy=~/gcf/policies/mypolicy1 applet.html java -usepolicy[:policyfile] some.local.App
Protection Domains: A domain consists of a set of objects belonging to a principal. A protection domain is based on an identity made up on demand. Permissions are granted to protection domains and not directly to classes or objects.
HTML version of Basic Foils prepared May 19 99

Foil 68 JAVA Fine-grained Access Control-4

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Access Control: The java.security.AccessController class implements a dynamic stack inspection algorithm. The method checkPermission() provides permission grant check. Example: FilePermission p = new FilePermission("/tmp/junk", "read");
AccessController.checkPermission(p);
Privilege: Privileges are used to grant temporary permission to less-trusted code. Whenever a resource access is attempted, all code traversed by the execution thread up to that point must have permission for that resource access, unless some code on the thread has been marked as "privileged". That is, suppose access control checking occurs in a thread of execution that has a chain of multiple callers. When the AccessController checkPermission method is invoked by the most recent caller, it decides whether to allow or deny the requested access.
HTML version of Basic Foils prepared May 19 99

Foil 69 JAVA Fine-grained Access Control-5

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The AccessController checkPermission algorithm is as follows:
  • If the code for any caller in the call chain does not have the requested permission, AccessControlException is thrown, unless the following is true - a caller whose code is granted the said permission has been marked as "privileged" and all parties subsequently called by this caller (directly or indirectly) all have the said permission.
HTML version of Basic Foils prepared May 19 99

Foil 70 JAVA Fine-grained Access Control-6

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Marking code as "privileged" enables a piece of trusted code to temporarily enable access to more resources than are available directly to the code that called it. This is necessary in some situations. For example, an application may not be allowed direct access to files that contain fonts, but the system utility to display a document must obtain those fonts, on behalf of the user. In order to do this, the system utility becomes privileged while obtaining the fonts.
The Secure Class Loader, java.security.SecureClassLoader, tracks the code source and signatures of each class, and hence assigns classes to protection domains.
HTML version of Basic Foils prepared May 19 99

Foil 71 JAVA Fine-grained Access Control-7

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Here is what the usage of privileged code looks like. Note the use of Java's inner classes capability:(If you are using an anonymous inner class, any local variables you access must be final to make JAVA language looks like having closures.)
somemethod() {
<normal code>
AccessController.doPrivileged (new PrivilegedAction()
{
public Object run()
{ <insert dangerous code here> return null; }
});
<more normal code>
}
HTML version of Basic Foils prepared May 19 99

Foil 72 Java Security-Related Tools

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The keytool is used to create pairs of public and private keys, to import and display certificate chains, to export certificates, and to generate X.509 v1 self-signed certificates and certificate requests that can be sent to a certification authority.
The jarsigner tool signs JAR (Java ARchive format) files and verifies the authenticity of the signature(s) of signed JAR files.
The Policy Tool creates and modifies the policy configuration files that define your installation's security policy. The Policy Tool has a graphical user interface to define policies.
HTML version of Basic Foils prepared May 19 99

Foil 73 How to sign Java Code

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Currently (1999), separate vendors have the following major code-signing tools;
  • Netscape's Object Signing
  • Microsoft's Authenticode
  • Sun's JDK 1.1 Code Signing
  • Sun's Java 2 Code Signing
Though Java is designed to be portable, there are various vendor specific code signing tools that make signed Java code incompatible in others environment. Having various complexity levels , vendor dependencies for leaving sandboxes, giving different control mechanisms to user makes them independent from each other.
HTML version of Basic Foils prepared May 19 99

Foil 74 Signing Classes with the Netscape Object Signing Tool

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Get a signing certificate from a CA, Certificate Authority, listed at https://certs.netscape.com.
Import the certificate to your Netscape Communicator browser.
Use The Netscape Object Signing Tool, which is a command line program, signtool, to sign JAR files. (Note that digital signature information is transmitted in JAR files);
Refer to the signed code as <APPLET CODE="signed.class" ARCHIVE="myjarfile.jar">
Use signtool to sign the classes and create a JAR file: signtool -d"path to certificate" -k"my CA" -e ".class" -Z myjar.jar
HTML version of Basic Foils prepared May 19 99

Foil 75 Netscape Object Signing Tool -2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Some useful options of signtool is illustrated as following;
  • signtool -d"path to certificates" -l list available certificates in your database
  • signtool -d"<path to certificate>" -v myjar.jar Check validity of signature on jar file whether it is tampered or not.
  • signtool -d"<path to certificate>" -w myjar.jar Check who signed myjar.jar
Adding Capabilities to Signed Classes: The Netscape Capabilities library provides a class called the Privilege Manager which turns on-off privileges for incoming program requests.
HTML version of Basic Foils prepared May 19 99

Foil 76 Netscape Object Signing Tool -3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
For the first request, the Privilege Manager asks the Netscape user whether the privilege should be granted, showing the certificate used to sign the code requesting the privilege. Grants are valid for lifetime of the applets.
Example privileges are UniversalFileAccess, UniversalSendMail, UniversalExitAccess, UniversalExecAccess, PrivateRegistryAccess.
  • import netscape.security.PrivilegeManager;
  • import netscape.security.ForbiddenTargetException; . . .
  • try { PrivilegeManager.enablePrivilege("UniversalFileRead");
  • ta.appendText("Read enabled!\n");
  • } catch (ForbiddenTargetException fte) {
  • ta.appendText("Read not enabled.\n");
  • ta.appendText(fte.toString());
  • }
HTML version of Basic Foils prepared May 19 99

Foil 77 Signing Java Applets with Microsoft's Authenticode

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Get an Authenticode Certificate, e.g., from digitalid.verisign.com/developer/ms_pick.htm.
Get Microsoft Java SDK, from www.microsoft.com/msdownload/java/sdk/31f/SDK-JAVA.asp
Prepare archive file , in Microsoft's CAB format, cabarc N test.cab *.class
Use Microsoft Security Zones concept. By default, a security zone, assigned a security level, is a group of Web sites. The available levels are Low, Medium, High, Custom.
signcode -j JavaSign.dll -jp High -spc c:\myCert.spc -v a:\myKey.pvk -n "My Applet Software" -i http://www.mywebpage.com/ myapp.cab where -j is to sign java code, -jp to pass parameter to JavaSign.dll, zone level, -i information page for the software that user can check.
HTML version of Basic Foils prepared May 19 99

Foil 78 Microsoft's Authenticode 2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
To test signature chkjava test.cab
To access applets from browser html tag is like <APPLET CODE= "MyApplet.class"> <PARAM name="cabbase" VALUE="myapp.cab"> </APPLET>
makecert -sk myKey.pvk -n "CN=Your Name" myCert.cer provides unauthorized certificate with key.
cert2spc myCert.cer myCert.spc provides signing certificate.
HTML version of Basic Foils prepared May 19 99

Foil 79 Signing Code with Sun's JDK 1.1.x

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Sun has its own set of signing tools, which have evolved along with the JDK.
The JDK ships with a command-line tool called javakey. "javakey" provides management of a database of entities (people, companies, etc.) and their public/private keys and certificates.
HotJava and the appletviewer program that comes with the JDK can validate JARs signed by javakey. Since the VMs in Communicator and Internet Explorer do not support javakey signing, in order to run javakey-signed applets with those browsers, users must download and install Sun's Java Plug-In.
HTML version of Basic Foils prepared May 19 99

Foil 80 Signing Code with Sun's JDK 1.1.x-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Some examples of using javakey
javakey -cs your_name :makes a new signer
javakey -ld : list the database (stored in identitydb.obj file by default)
javakey -gk your_name DSA 512 : generates new key pair with modulus 512
javakey -gc cert_directives.dir : generate a certificate using the directive file "cert_directives.dir"
javakey -dc outfile.509 : display the certificate contents from the certificate file
HTML version of Basic Foils prepared May 19 99

Foil 81 Signing Code with Sun's JDK 1.1.x-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
javakey -gs signMyApplet.dir Animator.jar: sign the applet, i.e. Animator.jar from the directives file signMyApplet.dir
  • ( Making jar files is done as following:
  • jar cvf Animator.jar AnimatorApplet.class )
  • As an example try to browse a signed applet which is at URL
javakey -h: brings the help menu for all the available options
Note that certificates and the keys produced by javakey are all in DER format.
HTML version of Basic Foils prepared May 19 99

Foil 82 Browsing Signed Applets

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
http://java.sun.com/security/signExample/ contains an applet signed by Duke
To run the applet with appletviewer,
  • First get a copy of Duke's certificate and store it in a file named Duke.x509
  • Make an identity Duke in your JDK identity database in your local machine;
    • % javakey -c Duke true
  • Import Duke's certificate into your identity database,
    • % javakey -ic Duke Duke.x509
  • Run the applet signed by Duke
HTML version of Basic Foils prepared May 19 99

Foil 83 The Java Authentication Framework

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The basic concepts are
Principal Interface; this describes real-world entities like persons, companies etc.
Identity class; an identity is derived from Principal Interface and has property corresponding to a public key
Certificate class; a certificate has two properties of class Identity: one is the Identity that is being certified, and the other Identity is a guarantor, with which the principal is associated for this certificate.
To keep identities safe from conflicts, e.g., " G. Fox" at NPAC and "G. Fox" at Sun Inc. , Java defines IdentityScopes.
An IdentityScope may have other IdentityScopes in it. For example, Syracuse University is an IdentityScope, and it contains the NPAC IdentityScope.
HTML version of Basic Foils prepared May 19 99

Foil 84 The Java Authentication Framework-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Each Java Virtual Machine has a system IdentityScope, which keeps unique identities in its scope, and is available to all Java programs in this VM.
  • It is best to use your own identity scope and add it to the scopes contained in the system IdentityScope.
Java 1.1 requires applets to be signed to be able to take advantage of this framework
HTML version of Basic Foils prepared May 19 99

Foil 85 Signing Code with Sun's Java 2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The javakey tool from JDK 1.1 has been replaced by two tools in Java 2.
keytool manages keys and certificates in a database. jarsigner is responsible for signing and verifying JAR files. The keystore, that contains certificate and key information, replaces the identitydb.obj from JDK 1.1.
Java 2 does allow Certificate Authorities to sign generated certificates
Useful command line examples are
keytool -alias keyname -genkey : Generating a public and private key pair and self-signed certificate.
keytool -storepasswd to change password. Note that keystore stores keys, and identity information necessary for certificates protected under a password.
HTML version of Basic Foils prepared May 19 99

Foil 86 Signing Code with Sun's Java 2-II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
keytool -list view the fingerprints of certificates in the keystore.
keytool -list -v view the personal information about the issuer and owner of the certificate.
keytool -identitydb - Import information from a JDK 1.1.x-style identity database.
keytool -keypasswd - Assign a password to a private key in a key/certificate entry.
keytool -printcert - Print out the information in a specified file containing a certificate.
keytool -certreq -alias keyname -file requestfile :Generate a certificate request.
HTML version of Basic Foils prepared May 19 99

Foil 87 Signing Code with Sun's Java 2-III

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
keytool -import -alias newalias -trustcacerts -file response :import certificates from authorities.
keytool -export -alias keyname -file mycert : Export
jarsigner SignMe.jar keyname sign a jar file
jarsigner -verbose SignMe.jar keyname monitor signing process
jarsigner -verify Unknown.jar verify signing of a file
jarsigner -verify -verbose -certs Unknown.jar More detailed check.
Running a Signed Applet
keytool -import -alias analias -file acert : Import to run others signed programs
HTML version of Basic Foils prepared May 19 99

Foil 88 Signing Code with Sun's Java 2-IV

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Make a Simple Policy for Signed Applets
Example .java.policy is
keystore ".keystore";
grant signedBy "friend";
codeBase "http://www.friendly.com/~mybuddy/applets/"
{
permission java.io.FilePermission "c:\\tmp\\*", "write";
};
HTML version of Basic Foils prepared May 19 99

Foil 89 Some Comparisons of Sign Tools

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Differences Between Netscape Object Signing and JDK 1.1.x javakey
Netscape Object Signing only works within Communicator. JDK 1.1 signed applets can work in any browser, but with Java Plug-In for the applet to leave the sandbox.<APPLET> tag must be changed by HTMLConverter for plugin use.
JDK 1.1 javakey-signed applets that are trusted get complete access to the host while Netscape Object Signing prompts for specific actions.
JDK 1.1 users can generate their own certificates without needing a certificate authority.
IN general, javakey is less useful than the others.
HTML version of Basic Foils prepared May 19 99

Foil 90 Some Comparisons of Sign Tools - 2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Comparing Authenticode to Netscape Object Signing
Netscape has finer-grained access to resources. Microsoft simply gives an access level instead of dealing with privileges, which is easy for developers.
Microsoft's Authenticode is more simple for end-user. Netscape prompts to user to grant permission for each privilege request. User has more control but may get exhausted with unrelated security questions.
HTML version of Basic Foils prepared May 19 99

Foil 91 Secure Electronic Transaction SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This standard was released May 31 1997 and is designed to support electronic bankcard transactions i.e. to enable electronic shopping on the Internet(Web)
http://www.mastercard.com/set and http://www.setco.org/download.html have complete specification for users and developers (about 1000 pages!)
Partners were Mastercard, GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems, Verisign and Visa
Goals included rapid development of this application in an interoperable fashion consistent with world wide standards
  • make certain technology meets US export rules
Need to authenticate cardholders, merchants and financial service operators.
Provide confidentiality and integrity for payment data
HTML version of Basic Foils prepared May 19 99

Foil 92 Electronic Shopping Experience - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
1)Cardholder browses for items to buy by:
  • Use of a Web browser on merchant's Web site
  • Viewing merchant's catalog on a CDROM
  • Looking at Paper Catalog
2)Cardholder selects items to be purchased
3)Order form with total cost and items purchased is either generated by PC software or over the web by electronic shopping software
  • Price may be subject to haggling between merchant and customer
4)Cardholder selects payment method. SET covers case where this is a charge card
HTML version of Basic Foils prepared May 19 99

Foil 93 Electronic Shopping Experience - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
5)Cardholder sends merchant a completed order along with payment instructions. (these will be digitally signed by cardholders possessing certificates)
6)Merchant requests payment authorization from the cardholder's financial institution
7)Merchant sends confirmation of order
8)Merchant ships the purchased goods or provides requested services from the order
9)Merchant requests payment from the cardholder's financial institution
SET covers items 5) 6) 7) and 9)
HTML version of Basic Foils prepared May 19 99

Foil 94 Features of SET - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Confidentiality of Information: This implies that payment data from cardholder can only be accessed by desired recipient (the merchant). They note this stops fraud and increases customer confidence which will help jumpstart electronic shopping
  • This is implemented by encrypting messages with a secret key method
Integrity of Data: This implies that data is not altered due to either fraud or network error during transmission between parties.
  • This is implemented using digital signatures
Cardholder Account Authentication: Merchant needs to be assured that customer is a legitimate user of a particular payment card account number.
  • This is implemented using digital signatures and cardholder certificates
HTML version of Basic Foils prepared May 19 99

Foil 95 Features of SET - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Merchant Authentication: This assures customer that merchant is legitimate and has the necessary relationship with a financial organization so that they can safely shop with merchant
  • Digital signatures and merchant certificates implement this
Interoperability: This means SET must not choose any one hardware or software platform and be implementable for world wide commerce
  • SET uses well defined protocols and formats compliant with best cryptographic practice. It can be implemented by any platform (as technical manual is 700 pages long, it is a non trivial investment to implement it!)
HTML version of Basic Foils prepared May 19 99

Foil 96 SET Encryption Summary

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
HTML version of Basic Foils prepared May 19 99

Foil 97 Sample SET Cryptography Use

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Alice wishes to sign a property description and send to Bob
There are 10 steps
1)Run property description through hash algorithm to get a message digest to use later to assure integrity of message.
  • This is digital fingerprint of property description
HTML version of Basic Foils prepared May 19 99

Foil 98 Sample SET Cryptography Steps 2 to 5

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
2)Alice encrypts the message digest with her private signature key to produce the digital signature
3)She chooses a secret key encryption algorithm and generates a random symmetric(secret) key. This is used to encrypt an amalgam of 3 items:
  • Property description
  • Digital Signature
  • Copy of her certificate which contains her public signature key
4)Alice must already know Bob's "key-exchange" public key which would be in his certificate. Alice encrypts her random secret (symmetric) key with Bob's public key. This is referred to as the digital envelope
5)Alice sends to Bob a message containing 4 entities in 3) and 4) above
HTML version of Basic Foils prepared May 19 99

Foil 99 Sample SET Cryptography Step 6

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
6)Bob receives the message from Alice and decrypts the digital envelope with his own private key-exchange key to retrieve the random secret key
HTML version of Basic Foils prepared May 19 99

Foil 100 Sample SET Cryptography Steps 7-10

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
7)Bob uses the secret key to decrypt property description, Alice's signature and her certificate
8)Bob decrypts Alice's digital signature with her public key which he gets from her certificate. This recovers message digest (which is 160 bit) of property description
9)Bob uses same hash algorithm as Alice on her property description. He produces a new message digest of the decrypted property description
10)Bob compares his calculated with transmitted message digest
  • If they are exactly the same, then the material was not altered in transit and indeed came from Alice!
  • If they are not the same, notify authorities
HTML version of Basic Foils prepared May 19 99

Foil 101 Structure of Public Key System in SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Certificates are issued hierarchically starting with a root certificate known to all SET software
Each certificate is signed with private key of parent. The root is self signed
GCA = Geopolitical CA
CCA = Cardholder CA
PCA = Payment Gateway CA
MCA = Merchant CA
CA = Certificate Authority
Root
Brand
GCA
CCA
MCA
PCA
Cardholder Signature
Merchant Signature
Merchant Key Exchange
Payment Gateway Key Exchange
Payment Gateway Signature
E.g. Visa Mastercard
HTML version of Basic Foils prepared May 19 99

Foil 102 Features of Public Key System in SET - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Note that Merchants and Financial Organizations have separate asymmetric key-pairs for the "symmetric key-exchange" and digital signature process.
Note cardholders do not need a key exchange key-pair
Note digital signature certificates are exchanged in protocol and need not be known ahead of time whereas one must know the public key with which to encrypt the secret key
SET uses what they call a dual signature but which is really a signed double message
Often one needs to conduct a transaction where two parts are intrinsically linked e.g. An offer from Bob to Alice to buy her property and an authorization to the bank to transfer the funds
Bob wishes the offer to be seen by Alice but keep the bank authorization confidential
HTML version of Basic Foils prepared May 19 99

Foil 103 Features of Public Key System in SET - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
To form a dual signature, convert the two messages separately into two message digests
  • concatenate the two messages and form the message digest of the combination
  • Use this combined message digest to form dual digital signature
If documents are 1 and 2, send document 1, digest of document 2 and dual digital signature to party that can see message 1 but for whom message 2 is not be seen.
  • Analogously for other party and document 2
This strategy allows one to intrinsically link messages in a legally provable fashion but confidentiality is preserved
HTML version of Basic Foils prepared May 19 99

Foil 104 Cardholder Registration Process in SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This is how cardholder obtains the necessary certificate from the certificate authority.
Note this is specific to particular bank card used
Cardholder software must store certificate safely and must generate asymmetric key-pair
The CA authority must be told the cardholder's public key
HTML version of Basic Foils prepared May 19 99

Foil 105 Merchant Registration Process in SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Here the merchant gets the necessary two certificates which are tied to a particular financial organization
HTML version of Basic Foils prepared May 19 99

Foil 106 Purchase Request Process in SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This involves a dual signature of the order information (for merchant)and payment instruction (for payment gateway) by the cardholder's software
HTML version of Basic Foils prepared May 19 99

Foil 107 Payment Authorization and Capture Processes in SET

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
There is an initial payment authorization process followed by a similar payment capture cycle
The Merchant sends the cardholder's payment instruction (which cannot be read by merchant as encrypted with payment gateway's public key)
HTML version of Basic Foils prepared May 19 99

Foil 108 SSL and S/MIME

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
These are the web standards to enable server communications (SSL) and e-mail (S/MIME) on the internet
See http://home.netscape.com/info/security-doc.html ( multiple frames describing SSL S/MIME and certificates)
Both these mechanisms use the standard strategy of public key cryptography to initiate transfer and secret key for message transfer
Message transfer is 40 bit RC4 (export) and 128 bit RC4 (internal)
Public key cryptography is 1024 bit
HTML version of Basic Foils prepared May 19 99

Foil 109 SSL from Netscape I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
SSL provides a security "handshake" (certificates and public keys) that is used to initiate the TCP/IP connection. This handshake results in the client and server agreeing on the level of security they will use and fulfills any authentication requirements for the connection.
Thereafter, SSL's only role is to encrypt and decrypt the bytestream of the application protocol being used (for example, HTTP, NNTP, or Telnet). This means that all the information in both the HTTP request and the HTTP response are fully encrypted, including the URL the client is requesting, any submitted form contents (including things like credit card numbers), and HTTP access authorization information (usernames and passwords), and all the data returned from the server to the client.
Netscape Navigator includes embedded Certificate Authority (CA) keys for certain CAs, including our test CAs.
  • As new CAs come online, we will embed their keys as well.
HTML version of Basic Foils prepared May 19 99

Foil 110 SSL from Netscape II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
These embedded keys allow Netscape Navigator to verify the legitimacy of arbitrary servers. See the Document Information dialog to inspect both the identity of a given server as well as the identity of the CA that issued the server its certificate.
SSL requires servers to have certificates issued by a Certificate Authority; Netscape Commerce Server includes a mechanism to easily acquire such a certificate.
Currently, Netscape Navigator does not include support for NNTP over SSL or application protocols other than HTTP; however, such support will be available soon.
Because HTTP+SSL (or "https") and HTTP are different protocols and typically reside on different ports (443 and 80, respectively), the same server system can run both secure and insecure HTTP servers simultaneously.
  • This means you can provide some information to all users using no security, and other information only securely, if you so choose. For instance, your "storefront" and merchandise catalog could be insecure, and your ordering and payment documents and forms could be secure.
HTML version of Basic Foils prepared May 19 99

Foil 111 SSL from Netscape III

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Browsers that do not implement support for HTTP over SSL will naturally not be able to access "https" URLs.
  • One of the reasons we are using a different URL access method ("https" instead of just "http") is so non-SSL browsers will gracefully refuse to allow insecure submission of forms that expect to be submitted securely.
  • That is, if a document served by a normal HTTP server contains a fill-out form that allows a user to enter his or her credit card number, and that form's submission action is an "https" URL (because the document's author expects the form to be submitted securely), a non-SSL browser will not even try to submit the form (typically giving a "cannot submit" error message instead).
  • Were a separate URL access method not being used, the browser would try to submit the form, passing the credit card number over the net in the clear, and the submission would fail anyway.
HTML version of Basic Foils prepared May 19 99

Foil 112 Netscape's Description of S/MIME

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
S/MIME is a new standard for encrypted and digitally signed electronic mail. Developed by RSA, S/MIME enables users of Web messaging clients such as Netscape Messenger to send encrypted messages and authenticate received messages.
S/MIME delivers message encryption and authentication with the flexibility, interoperability, and cost-effectiveness of Web-based messaging.
S/MIME offers users the following basic features:
  • Encryption for message privacy
  • Sender authentication with digital signatures
  • Tamper detection
  • Interoperability with other S/MIME-compliant software
  • Seamless integration into Netscape Messenger
  • Cross-platform messaging
See http://www.rsa.com for S/MIME and SET discussion
HTML version of Basic Foils prepared May 19 99

Foil 113 Generating Certificates on Unix-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
"ssleay" is a public domain tool to produce certificates and keys on NPAC systems.
"ssleay" is installed in the following directory; /usr/npac/lib/ssl/bin
ssleay program has useful utilities related to cryptography
To generate new certificate and key files, type the following
ssleay req -new -x509 -nodes -out myCertificate.pem -keyout myPrivateKey.pem
and follow the instructions produced by the program.
A sample session is on following foil:
-----
HTML version of Basic Foils prepared May 19 99

Foil 114 Generating Certificates on Unix-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:NY
Locality Name (eg, city) []:Syracuse
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Syracuse University
Organizational Unit Name (eg, section) []:NPAC
Common Name (eg, YOUR name) []:Geoffrey Fox
Email Address []:gcf@npac.syr.edu
HTML version of Basic Foils prepared May 19 99

Foil 115 Sample Certificate and primary Key

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
HTML version of Basic Foils prepared May 19 99

Foil 116 Secure Server Example-NPAC Grading System-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
NPAC Grading System is a good example of the usage of the certificates and private and public keys;
HTML version of Basic Foils prepared May 19 99

Foil 117 Secure Server Example-NPAC Grading System-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The original primitive version of the Grading System had two security flaws
  • 1- Communication between the browser and the database server was not a secure channel.
  • 2- The CGI directories, which provide access to the database, was not completely private to the public.
  • Because of the design issues of the Oracle database web link, database passwords are located in the CGI directories. Somebody could easily steal the password, access the database and modify the records.
HTML version of Basic Foils prepared May 19 99

Foil 118 Secure Server Example-NPAC Grading System-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Frustrated Evil People
The New Secure System:
HTML version of Basic Foils prepared May 19 99

Foil 119 Secure Server Example-NPAC Grading System-4

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The current version of the system is believed to be secure because
  • 1- It uses a SSL web server, which provides secure communication using public cryptography standards.
  • 2- CGI files, and server private key, are located in a completely private area, which are protected by Unix file protection mechanisms.
    • Since the server does not allow any other user to write CGI programs on the same server, it is not possible for someone to write CGI scripts reading others private files through the web.
  • 3- It uses user authentication and access privileges to access and update data in the database.
  • 4- The open issue in such a system is that system administrators can access to the files and the database.
The URL is https://students.npac.syr.edu:5557/grading.html
HTML version of Basic Foils prepared May 19 99

Foil 120 Java Security Manager

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
This implements the overall security strategy and is completely customizable by those authorized. Thus browsers can implement a particular Security Manager but as mentioned Applets cannot!
In particular the Security Manager implements the differences between Java Applets (no local file operations etc.) and Applications
  • Note you can download a Java Application that has NO Security Manager restrictions!
In general Security Manager controls thread access, OS access, network access and other Java class access.
It controls installation of Class Loaders
It (will) process encryption based authentication mechanisms
HTML version of Basic Foils prepared May 19 99

Foil 121 Java Security Package

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Because applets under Java 1.0&1 were so closely supervised through the sandbox mechanism , they could not perform some useful functions.
It is useful and necessary for users to be able to assign different levels of security with respect to provider of applets.
  • Applets from trusted sites may have all the privileges of local applications.
The java.security package contains libraries for insuring the integrity of data and for electronic signatures.
HTML version of Basic Foils prepared May 19 99

Foil 122 Java Digital Signatures-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Java Security Package comes with DSA (Digital Signature Algorithm) including following three algorithms:
  • To generate a key pair, by KeyPairGenerator class
  • To sign a message, by Signature class
  • To verify a signature, by Signature class
A message digest , fingerprint, of an applet provides to check whether the applet is altered or not. If altered applet, then the finger print will not match. However, both can be intercepted. It is easy for an attacker to modify the applet and prepare new fingerprint for it.
Java Digital Signatures are used to authenticate an applet in this situation. Using public key cryptography, based on public and private keys, decrypting information can be released to public (via public key), but not the encrypting capability (such as private key).
HTML version of Basic Foils prepared May 19 99

Foil 123 Java Digital Signatures-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Assume Joe wants to send an applet to a group. First the group gets Joe's public key, then Joe use his private key to sign, encrypt, the applet and publish it. The group members get the signed applet and uses Joe's public key to open it. Since only Joe knows to encrypt the applet, they will be sure about the source.
Code authors can use standard cryptographic algorithms to embed a "certificate" into a Java class. Then, the users can precisely understand who implemented the code and signed. If somebody alters the code, the interloper would not be able to sign it with the original signature.
Once the signature is verified, one will be sure about the originality of the code. However, trusting to the original code is another security issue. Users may decide to use or not to use the code depending on their trust in the signer.
HTML version of Basic Foils prepared May 19 99

Foil 124 Some Other Security Systems

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Passwords on UNIX are stored using a hash based on encrypting 0 with a DES like secret algorithm with key based on password
Kerberos is a secret key cryptography system using a KDC -- Key distribution center which keep authorized people and their master keys
Sessions are assigned dynamically session keys which are used to encrypt with DES transmissions
Electronic mail systems include PEM (Privacy Enhanced Mail) which could use Kerberos like secret keys but in practice is based on public key certification with again DES for message transmission
PGP (Pretty Good Privacy) is similar to PEM and used for mail and file transmission
  • Note difficulties is public key certificate. This area will get a lot easier when Internet shopping promotes public key certification strategy
HTML version of Basic Foils prepared May 19 99

Foil 125 KERBEROS

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Kerberos is a secret key cryptography system using a KDC -- Key distribution center which keep authorized people and their master keys. A more precise statement is that the client has knowledge of an encryption key that is known by only the user and the authentication server. Similarly, each application server shares an encryption key with the authentication server, i.e., the server key. The Kerberos Authentication System uses a series of encrypted messages to prove to a verifier that a client is running on behalf of a particular user.
The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.
HTML version of Basic Foils prepared May 19 99

Foil 126 KERBEROS - 2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Kerberos is freely available from MIT. It provides the tools of authentication and strong cryptography over the network to help secure information systems across an entire enterprise.
Limitations of Kerberos
Kerberos is not effective against password guessing attacks;
To be useful, Kerberos must be integrated with other parts of the system.
Kerberos does not itself provide authorization, but V5 Kerberos passes authorization information generated by other services. In this manner, Kerberos can be used as a base for building separate distributed authorization services.
HTML version of Basic Foils prepared May 19 99

Foil 127 SESAME Security System

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
http://www.esat.kuleuven.ac.be/cosic/sesame3.html
SESAME (a Secure European System for Applications in a Multi-vendor Environment) is a European research and development project, part funded by the European Commission under its RACE program. It is also the name of the technology that came out of that project.
The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data.
SESAME is a construction kit. It is a set of security infrastructure components for product developers. It provides the underlying bedrock upon which full managed single sign-on products can be built.
Examples of such products are ICL's Access Manager and Bull SA's Integrated System Management AccessMaster (ISM AccessMaster).
  • Siemens (Software & Systems Engineering Ltd) is also using SESAME technology to improve its secure X.400 mail product set.
HTML version of Basic Foils prepared May 19 99

Foil 128 Details on SESAME I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
SESAME uses the widely accepted Generic Security Service API (GSS-API).
The user gets mechanism transparency.
To access the distributed system, a user first authenticates to an Authentication Server to get a cryptographically protected token used to prove his or her identity.
The user then presents the token to a Privilege Attribute Server to obtain a guaranteed set of access rights contained in a Privilege Attribute Certificate (or PAC). The PAC is a specific form of Access Control Certificate that conforms to ECMA and ISO/ITU-T standards.
HTML version of Basic Foils prepared May 19 99

Foil 129 Details on SESAME II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Access to protected resource is controlled by PAC and by an Access Control List (ACL) similar to the NPAC Grading System.
PAC protection is provided by temporary secret cryptographic keys shared pairwise between the participants.
SESAME supports Certification Authorities, X.509 Directory user certificates.
SESAME supports delegation, i.e., an application act on user's behalf.
SESAME security structure is explained at
http://www.esat.kuleuven.ac.be/cosic/sesame/relat/ecma-219.ps.Z
HTML version of Basic Foils prepared May 19 99

Foil 130 The GSS-API Security Interface

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Generic Security Services Application Program Interface (GSS-API) hides from its callers the details of the specific underlying security mechanism, leading to better application portability, and moving generally in the direction of a better interworking capability.
The GSS-API also completely separates the choice of security mechanism from choice of communications protocol.
A GSS-API implementation is viable across virtually any communications method.
GSS_API is an Internet and X/Open standard.
HTML version of Basic Foils prepared May 19 99

Foil 131 Globus System Security Policy and Requirements -- Overview

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Globus is a distributed computing system http://www.globus.org/security/policy.htm
Globus security mechanisms are intended for an environment in which "users" initiate "computations" that acquire, use and release multiple, geographically distributed "resources".
Some properties of these entities are:
  • The user population may be large and dynamic.
  • The resource population may be large and dynamic.
  • A computation may acquire, start processes on, and release resources dynamically during its execution.
HTML version of Basic Foils prepared May 19 99

Foil 132 Further Properties of Globus Entities

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The processes comprising a computation will communicate by using a variety of mechanisms, including unicast and multicast.
  • While these processes form a single fully-connected logical entity, low-level communication connections (e.g., TCP/IP sockets) may be created and deleted dynamically during program execution.
  • Resources may support different authentication and authorization mechanisms and policies and we will have limited ability to change these.
Users will have different user ids on different resources.
Resources and users may be located in multiple countries.
HTML version of Basic Foils prepared May 19 99

Foil 133 Globus Application Requirements

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
In general, applications running under Globus will have requirements for all standard security requirements:
Authentication: parties can prove their identity,
authorization: a subject is given access only to resources to which they are entitled to use,
integrity: the contents of a communication between two or more parties have not been altered,
privacy: the contents of a communication are not disclosed to unauthorized parties, and
non-repudiation: the sender of a communication cannot deny that they were the sender, and the receiver cannot deny receipt.
HTML version of Basic Foils prepared May 19 99

Foil 134 Relevant Components of Globus

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
User (U)The person or agent on whose behalf the Globus computation is being run.
UserProxy (UP)A process (i.e. session manager) given permission to act on behalf of the user for a limited duration of time.
Process (P)A logical entity, created via the process management API which performs computation on a particular resource on behalf of a particular user.
Resource (R)A computer, file system, network or other other object that can be used as part of a computation.
ResourceProxy (RP)An agent (i.e. process or resource) that has permission to act on behalf of the resource.
  • Examples of resource proxies include process managers and resource managers.
HTML version of Basic Foils prepared May 19 99

Foil 135 Issues in the Globus Security Model

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Credential. A credential is a piece of information that is used to prove the identity of a subject. Examples of a credential include passwords and private keys. We distinguish between credentials that are introduced by Globus, Globus credential, and credentials that are used only on a specific resource, resource credential,
Subject. Authorization is the process by which we determine if a subject is allowed to access or use and object. In Globus, a subject is generally a user, or a process operating on behalf of a user.
  • A Globus subject is a subject that is recognized by components in the Globus system.
  • A resource subject is a subject that is only recognized by a specific resource.
Trust. We say that A trusts B if A assumes that any information sighed by B is believed by B to be "correct".
Trust Domain. A trust domain is an administrative structure within which local security policy holds. For example, authentication may not be required between subjects within a trust domain.
HTML version of Basic Foils prepared May 19 99

Foil 136 Elements of Globus Security Policy I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Authentication is required on all interactions between a user proxy and a resource proxy. A process may authenticate itself to another process. No other authentication is required.
All authentication is mutual.
A user proxy can interact with resource proxies on behalf of a user, and with the same privileges; but this power is granted only for a limited time. In other words, if a resource proxy trusts a user, it will also trust a user proxy for that user.
Mutual trust exists between resource proxies associated with the same resource.
HTML version of Basic Foils prepared May 19 99

Foil 137 Elements of Globus Security Policy II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
A process trusts the process manager that created it. A process manager is a resource proxy that is responsible for process creation.
A process manager and the processes it creates are assumed to execute within a single trust domain.
There is a mutual trust relationship between all processes created by the same user proxy/resource proxy pair.
Access control for a resource is specified by local policy and implemented via local mechanisms.
Any Globus specific subject can be mapped into resource specific subjects (e.g. user ids) for local access control mechanisms.
HTML version of Basic Foils prepared May 19 99

Foil 138 Globus Security Functional Requirements - I

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Single sign-on: A user should be able to authenticate once to "Globus" (e.g., when starting a computation); a computation should then be able to acquire, use, and release resources, and communicate internally, without additional authentication from the user.
Protection of credentials: User credentials (passwords, private keys, etc) must be protected.
Interaction with local policies: Globus security policy must interface with locally enforced security policies, mechanisms and implementations, such as firewalls, Kerberos authentication, one-time passwords, etc.
Support for multiple implementations: The security policy should not dictate a specific implementation technology. Rather, it should be possible to implement the security policy with a range of security technologies, for example, X.500 based public key, PGP public key, Kerberos shared secret and SESAME.
HTML version of Basic Foils prepared May 19 99

Foil 139 Globus Security Functional Requirements - II

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Portability: We require the security policy be portable in two senses. We must support different security mechanisms, such as those built around X.509 certificates and Kerberos.
Exportability: Code can be (a) exported and (b) run in multinational testbeds. In short, the exportability issues mean that Globus security policy cannot directly or indirectly require the use of privacy.
Robustness. The security algorithms must be designed in such a way that if a component is not being used, that component can be restarted without requiring any other component to be restarted. That is, security algorithms must localize their use of system state
HTML version of Basic Foils prepared May 19 99

Foil 140 JavaScript Security Model

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
JavaScript Security depends on the implementation of the browsers.
There are two security policies in JavaScript:
  • Same Origin Policy: Navigator version 2.0 and later automatically prevents scripts on one server from accessing properties of documents on a different server, including user session histories, directory structures etc..
  • Signed Script Policy: The JavaScript security model for signed scripts is based upon the Java security model for signed objects. The scripts you can sign are inline scripts (those that occur within the SCRIPT tag), event handlers, JavaScript entities, and separate JavaScript files.
HTML version of Basic Foils prepared May 19 99

Foil 141 JavaScript Security Issues

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Signed Script Policy comes with Netscape version 4.
In Navigator 3.0, one could use data tainting to get access to additional information.
  • This was very clumsy and almost impossible to use and in particular to make precise
However, Navigator 4.0 replaces data tainting with the signed script policy. Because signed scripts provide greater security and greater precision than tainting, tainting has been disabled in Communicator 4.x.
HTML version of Basic Foils prepared May 19 99

Foil 142 Same Origin Policy

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
When loading a document from one origin, a script loaded from a different origin cannot get or set certain predefined properties of certain browser and HTML objects in a window or frame.
Origin is defined as protocol://host, where host may include optional parts of URL including :port, part of an URL.
Any applets in the document are also subject to origin checks when calling JavaScript.
The same origin policy is the default policy since Netscape 2.
Properties subject to origin check
HTML version of Basic Foils prepared May 19 99

Foil 143 Signed Script Policy-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The JavaScript security model for signed scripts is based upon the Java security model for signed objects. The scripts you can sign are inline scripts (those that occur within the SCRIPT tag), event handlers, JavaScript entities, and separate JavaScript files.
A signed script requests expanded privileges, gaining access to restricted information. It requests these privileges by using LiveConnect and the Java classes referred to as the Java Capabilities API. These classes add facilities to and refine the control provided by the standard Java SecurityManager class.
Access control decisions are given based on who, called principal, is allowed to do what, called target, and the privileges associated with the principal.
HTML version of Basic Foils prepared May 19 99

Foil 144 Signed Script Policy-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Netscape's Page Signer tool provides signing of scripts. Page Signer associates a digital signature with the scripts on an HTML page.
A single HTML page can have scripts signed by different principals
The digital signature is placed in a Java Archive (JAR) file.
JAR files may include the JavaScript source if one sign a JavaScript file with Page Signer.
  • ( If you sign an inline script, event handler, or JavaScript entity, Page Signer stores only the signature and the identifier for the script in the JAR file. If you sign a JavaScript file with Page Signer, it stores the source in the JAR file as well.)
HTML version of Basic Foils prepared May 19 99

Foil 145 Signed Script Policy-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The associated principal allows the user to confirm the validity of the certificate used to sign the script. The user can ensure that the script hasn't been tampered with since it was signed. The user may grant privileges based on the validated identity of the certificate owner and validated integrity of the script.
An simpler alternative to using the Page Signer tool to sign scripts is to serve them from a secure server. On the browser, scripts act as though they were signed with the public key of that server. There is no need to sign the individual scripts.
SSL servers are particularly helpful if scripts are dynamically generated on the server side.
HTML version of Basic Foils prepared May 19 99

Foil 146 Codebase Principals-1

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
As does Java, JavaScript supports codebase principals. A codebase principal is a principal derived from the origin of the script rather than from verifying a digital signature of a certificate. Since codebase principals offer weaker security, they are disabled by default in Communicator.
To enable codebase principals, end users must add the appropriate preference to their Communicator preference file:
user_pref("signed.applets.codebase_principal_support", true);
If enabled, when the user accesses the script, a dialog displays similar to the one displayed with signed scripts. The difference is that this dialog asks the user to grant privileges based on the URL and doesn't provide author verification. It says that the script has not been digitally signed and may have been tampered with.
HTML version of Basic Foils prepared May 19 99

Foil 147 Codebase Principals-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
If a page includes signed scripts and codebase scripts, and signed.applets.codebase_principal_support is enabled, all of the scripts on that page are treated as though they are unsigned and codebase principals apply.
Netscape 4 always keeps track of codebase principals to use in enforcement of the same origin security policy whether codebase principals are disabled or enabled.
HTML version of Basic Foils prepared May 19 99

Foil 148 Scripts Signed by Different Principals

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Since JavaScript does not have internal protection mechanisms like Java, e.g., protected and private, and object properties including methods can be changed at runtime, simple signing of scripts is sometimes not secure enough.
Different scripts from different principals on the same page can change each other's behaviour.
Security of the JavaScript is ensured by the following assumption:
Mixed scripts on an HTML page operate as if they were all signed by the intersection of the principals that signed each script.
For example, assume principals A and B have signed one script, but only principal A signed another script. In this case, a page with both scripts acts as if it were signed by only A.
HTML version of Basic Foils prepared May 19 99

Foil 149 Principals of Windows and Layers

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
In order to protect signed scripts from tampering, Navigator 4.0 adds a new set of checks at the container level, where a container is a window or layer.
A script, which wants to access the properties of a signed container, should be signed by a superset of principals that signed the container.
If some scripts in a layer are signed by different principals, the special container checks apply to the layer.
HTML version of Basic Foils prepared May 19 99

Foil 150 Determining Container Principals

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Following structure is used (by Communicator) :
1. If this is the first script that has been seen on the page, assign this script's principals to be the principals for the window.
2. If the innermost container (the container directly including the script) has defined principals, intersect the current script's principals with the container's principals and assign the result to be the principals for the container. If the two sets of principals are not equal, intersecting the sets reduces the number of principals associated with the container. Done.
3. Else, find the innermost container that has defined principals. If the principals of the script are the same as the principals of that container, leave the principals as is. Else assign the current script's principals to be the principals of the container.
HTML version of Basic Foils prepared May 19 99

Foil 151 Identifying Signed Scripts

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
All signed scripts (inline script, event handler, JavaScript file, or JavaScript entity) require a SCRIPT tag's ARCHIVE attribute whose value is the name of the JAR file containing the digital signature ; <SCRIPT ARCHIVE="myArchive.jar" ID="a"> ... </SCRIPT>
To sign an inline script, you add both an ARCHIVE attribute and an ID attribute to the SCRIPT tag for the script you want to sign
To sign an event handler, you add an(only one) ID attribute for the event handler without specifying the ARCHIVE to the tag containing the event handler; <INPUT TYPE="button" VALUE="OK" onClick="alert('...') onClick="alert('A signed script')" ID="b">
To sign a JavaScript entity, you do not do anything special to the entity. Instead, the HTML page must also contain a signed inline script preceding the JavaScript entity.
HTML version of Basic Foils prepared May 19 99

Foil 152 Using Expanded Privileges

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Signed scripts use calls to Netscape's Java security classes to request expanded privileges.( like Java signed objects) For example, netscape.security.PrivilegeManager.enablePrivilege("UniversalSendMail")
When the script calls this function, the signature is verified, and if the signature is valid, expanded privileges can be granted. If necessary, a dialog displays information about the application's author, and gives the user the option to grant or deny expanded privileges.
Privileges are granted only in the scope of the requesting function and only after the request has been granted in that function. This scope includes any functions called by the requesting function. When the script leaves the requesting function, privileges no longer apply.
HTML version of Basic Foils prepared May 19 99

Foil 153 Targets

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
A target typically represents one or more system resources, such as reading files stored on a local disk or sending email on your behalf.
The Privilege Manager, with the aid of the Communicator client, keeps track of which principals are allowed to access which targets at any given time
The Privilege Manager enforces a distinction between granting a privilege and enabling a privilege. A script that has been granted a privilege has a potential power that is not yet turned on.
HTML version of Basic Foils prepared May 19 99

Foil 154 Targets-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The followings are some samples of system targets and the JavaScript methods that require privileges to check them:
UniversalFileRead:Setting a file upload widget
UniversalSendMail:Submitting a form to a mailto
UniversalBrowserRead:Using an about: URL other than about:blank
UniversalBrowserWrite:Setting any property of event object
UniversalBrowserRead: Getting the value of the data property DragDrop event
UniversalBrowserRead: Getting the value of any property of history object
UniversalPreferencesRead/Write: Getting setting the value of a preference of navigatorobject using the preference method
HTML version of Basic Foils prepared May 19 99

Foil 155 Importing and Exporting Functions

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
You might want to provide interfaces to call into secure containers (windows and layers). To do so, you use the import and export statements.
Exporting a function name makes it available to be imported by scripts outside the container without being subject to a container test.Importing a function into your scope creates a new function of the same name as the imported function. Calling that function calls the corresponding function from the secure container.
One should be very careful to not inadvertently allow access to an attacker
HTML version of Basic Foils prepared May 19 99

Foil 156 Weaknesses in the JavaScript Model

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
If one have signed scripts in pages he has posted to his site, it is possible to copy the JAR file from his site and post it on another site. As long as the signed scripts themselves are not altered, the scripts will continue to operate under his signature. "Programmer should force scripts to work only from his side."
When you export functions from your signed script, you are in effect transferring any trust the user has placed in you to any script that calls your functions.This means you have a responsibility to ensure that you are not exporting interfaces that can be used in ways you do not want.
HTML version of Basic Foils prepared May 19 99

Foil 157 Signing Scripts

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
For any script to be granted expanded privileges, all scripts on the same HTML page or layer must be signed. If you use layers, you can have both signed and unsigned scripts as long as you keep them in separate layers.
The Netscape Signing Tool (signtool on the command line) is a stand-alone command-line tool that creates digital signatures and uses the Java Archive (JAR) format to associate them with files in a directory. Previous versions of the signtool are known as zigbert and signPages.
The signtool script extracts scripts from HTML files, signs them, and places their digital signatures in the archive specified by the ARCHIVE attribute in the SCRIPT tag from the HTML files. It also takes care of copying external JavaScript files loaded by the SRC attribute of the SCRIPT tag.
HTML version of Basic Foils prepared May 19 99

Foil 158 Signing Scripts-2

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
The SCRIPT tags in the HTML pages can specify more than one JAR file; if so, signtool creates as many JAR files as it needs.
The signtool utility program helps to deal with certificate databases; for example signtool -L -d my_test_dir list the certificates stored in the certificate database *.db files in the specified directory. signtool -l -k nickname verifies an object-signing certificate with the specified nickname.
To sign a file using the Netscape Signing Tool;
1. Create an empty directory: % mkdir signdir
2. Put script files into it
3. Specify the name of your object-signing certificate and sign the directory:
% signtool -k MySignCert -Z testjar.jar signdir
HTML version of Basic Foils prepared May 19 99

Foil 159 Signing Scripts-3

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
Output will be
using key "MySignCert"
using certificate directory: /home/loginname/.netscape
Generating signdir/META-INF/manifest.mf file..
--> test.f
adding signdir/test.f to testjar.jar
Generating signtool.sf file..
Enter Password or Pin for "Communicator Certificate DB":XXXXX
adding signdir/META-INF/manifest.mf to testjar.jar
adding signdir/META-INF/signtool.sf to testjar.jar
adding signdir/META-INF/signtool.rsa to testjar.jar
tree "signdir" signed successfully
HTML version of Basic Foils prepared May 19 99

Foil 160 Signing Scripts-4

From Remarks on Internet and Java Security Basic Information Track Computational Science Course CPS616 -- Spring Semester 1999. *
Full HTML Index
4. Test the archive you just created:% signtool -v testjar.jar
using certificate directory: /home/loginname/.netscape
archive "testjar.jar" has passed crypto verification.
status path
------------ -------------------
verified test.f
To learn more details about the signtool, visit the URL:
http://developer.netscape.com/docs/manuals/signedobj/signtool/index.htm
http://developer.netscape.com/docs/manuals/signedobj/zigbert/index.htm
© Northeast Parallel Architectures Center, Syracuse University, npac@npac.syr.edu

If you have any comments about this server, send e-mail to webmaster@npac.syr.edu.

Page produced by wwwfoil on Wed May 19 1999