Full HTML for

Basic foilset Remarks on Java and Internet Security

Given by Geoffrey C. Fox at Web Certificate CPS616 Enhancement on Summer 1997 . Foils prepared August 4 1997
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
Implications for Commerce (the SET system)
Web Servers and Secure Sockets SSL
Some relevant technologies including Kerberos, S/MIME&#060 Clipper, PEM and PGP

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

 Denote Foils where Image Critical
Denote Foils where HTML is sufficient
1 Remarks on Internet and Java Security CPS616 Certificate Version Summer 97
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 Comments on Denial of Service
24 Some Attacking Concepts
25 Naïve way Viruses Spread themselves
26 The Java Security Model
27 What can applets do - I?
28 What can applets do - II?
29 What can applets do - III?
30 The Byte Code Verifier
31 Byte Code Verification
32 Why is type checking important!
33 Applet Class Loader
34 Java Security Manager
35 Introduction to Cryptography
36 Breaking an Encryption Scheme
37 Types of Cryptographic Function
38 Security Uses of Cryptography
39 Secret Key Cryptography
40 Uses of Secret Key Cryptography
41 Secret Key Authentication
42 Message Integrity with Secret Key Cryptography
43 Public Key Cryptography
44 Insecure Link Transmission with Public Key Cryptography
45 Authentication with public key Cryptography
46 Digital Signatures and Public Key Cryptography
47 Use of Digital Signatures with public key Cryptography
48 Hash and Message Digests
49 Some Math Behind Secret Key Cryptography
50 Some Math behind RSA Algorithm -I
51 Some Math behind RSA Algorithm -II
52 Certificate Authorities
53 Sample Certificate from Netscape
54 VeriSign Digital ID's or Certificates - I
55 VeriSign Digital ID's or Certificates - II
56 VeriSign's Description of Digital ID's
57 VeriSign's Description of Certificate Revocation I
58 VeriSign's Description of Certificate Revocation II
59 Secure Electronic Transaction SET
60 Electronic Shopping Experience - I
61 Electronic Shopping Experience - II
62 Features of SET - I
63 Features of SET - II
64 SET Encryption Summary
65 Sample SET Cryptography Use
66 Sample SET Cryptography Steps 2 to 5
67 Sample SET Cryptography Step 6
68 Sample SET Cryptography Steps 7-10
69 Structure of Public Key System in SET
70 Features of Public Key System in SET - I
71 Features of Public Key System in SET - II
72 Cardholder Registration Process in SET
73 Merchant Registration Process in SET
74 Purchase Request Process in SET
75 Payment Authorization and Capture Processes in SET
76 SSL and S/MIME
77 SSL from Netscape I
78 SSL from Netscape II
79 SSL from Netscape III
80 Netscape's Description of S/MIME
81 Some Other Security Systems
82 SESAME Security System
83 Globus System Security Policy and Requirements -- Overview
84 Further Properties of Globus Entities
85 Globus Application Requirements
86 Relevant Components of Globus
87 Issues in the Globus Security Model
88 Elements of Globus Security Policy I
89 Elements of Globus Security Policy II
90 Globus Security Functional Requirements - I
91 Globus Security Functional Requirements - II

Outside Index Summary of Material

HTML version of Basic Foils prepared August 4 1997

Foil 1 Remarks on Internet and Java Security CPS616 Certificate Version Summer 97

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
Geoffrey Fox
Syracuse University
NPAC
111 College Place Syracuse NY 13244 4100
3154432163
HTML version of Basic Foils prepared August 4 1997

Foil 2 Abstract of CPS616 Java and Internet Security Presentation

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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
Implications for Commerce (the SET system)
Web Servers and Secure Sockets SSL
Some relevant technologies including Kerberos, S/MIME&#060 Clipper, PEM and PGP
HTML version of Basic Foils prepared August 4 1997

Foil 3 Some Reference Material

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 4 Some General Issues I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 5 Some General Issues II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 6 Need for Security in Commerce - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 7 Need for Security in Commerce - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 8 Structure of Internet and Security-I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 9 Structure of Internet and Security-II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 10 Structure of Internet and Security-III

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 11 A PKZIP Anecdote

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 12 Downloading Software is Dangerous?

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 13 The Moldavia Pornographic Phone Scam

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 14 An Early Netscape DNS Bug

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 15 Tempest and Control Zones

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 16 Military Security Levels

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
DoD classifies information into 4 levels unclassified &#060 confidential &#060 secret &#060 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 August 4 1997

Foil 17 Firewalls and Gateways - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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--&#062outside 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 August 4 1997

Foil 18 Firewalls and Gateways II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 19 Encrypted Tunnels

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
These are used to communicate between two or more secure IntraNets
as opposed to previous discussions which was for Secure &#060--&#062 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 August 4 1997

Foil 20 The Great Clipper Controversy

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 21 Export Restrictions on Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 22 Denial of Service versus "Attacks"

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
There are two broad classes of "security" problems
  • 1) Deliberate attacks - NPAC suffered this 6 months 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
HTML version of Basic Foils prepared August 4 1997

Foil 23 Comments on Denial of Service

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 set 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 August 4 1997

Foil 24 Some Attacking Concepts

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 25 Naïve way Viruses Spread themselves

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 26 The Java Security Model

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 27 What can applets do - I?

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 28 What can applets do - II?

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 29 What can applets do - III?

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 30 The Byte Code Verifier

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 31 Byte Code Verification

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 32 Why is type checking important!

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 some 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 August 4 1997

Foil 33 Applet Class Loader

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 34 Java Security Manager

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 35 Introduction to Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
This is old technology first attributed to Julius Caesar who used the nifty cipher which replaced every latter 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 August 4 1997

Foil 36 Breaking an Encryption Scheme

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 37 Types of Cryptographic Function

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 38 Security Uses of Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 39 Secret Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 40 Uses of Secret Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 41 Secret Key Authentication

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 42 Message Integrity with Secret Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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
  • hashs (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 August 4 1997

Foil 43 Public Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
This is much than other approaches and was first published in 1975As we have discussed this has key feature of only requiring 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 August 4 1997

Foil 44 Insecure Link Transmission with Public Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
Suppose A has (public key,private key) &#060eA,dA&#062 and B keys &#060eB,dB&#062
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 August 4 1997

Foil 45 Authentication with public key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 46 Digital Signatures and Public Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 47 Use of Digital Signatures with public key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 48 Hash and Message Digests

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 49 Some Math Behind Secret Key Cryptography

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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&#060-&#0621 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 August 4 1997

Foil 50 Some Math behind RSA Algorithm -I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 &#060e,n&#062 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 August 4 1997

Foil 51 Some Math behind RSA Algorithm -II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 52 Certificate Authorities

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 53 Sample Certificate from Netscape

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
http://home.netscape.com/ newsref/ref/ netscape-test-ca.html
HTML version of Basic Foils prepared August 4 1997

Foil 54 VeriSign Digital ID's or Certificates - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 55 VeriSign Digital ID's or Certificates - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 56 VeriSign's Description of Digital ID's

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 57 VeriSign's Description of Certificate Revocation I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 58 VeriSign's Description of Certificate Revocation II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 59 Secure Electronic Transaction SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 has 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 August 4 1997

Foil 60 Electronic Shopping Experience - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 61 Electronic Shopping Experience - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 62 Features of SET - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 63 Features of SET - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 64 SET Encryption Summary

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
Full HTML Index
HTML version of Basic Foils prepared August 4 1997

Foil 65 Sample SET Cryptography Use

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 66 Sample SET Cryptography Steps 2 to 5

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 67 Sample SET Cryptography Step 6

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 68 Sample SET Cryptography Steps 7-10

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 69 Structure of Public Key System in SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 70 Features of Public Key System in SET - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 71 Features of Public Key System in SET - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 1but 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 August 4 1997

Foil 72 Cardholder Registration Process in SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 73 Merchant Registration Process in SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 74 Purchase Request Process in SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 75 Payment Authorization and Capture Processes in SET

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 76 SSL and S/MIME

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 77 SSL from Netscape I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 78 SSL from Netscape II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 79 SSL from Netscape III

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 80 Netscape's Description of S/MIME

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 81 Some Other Security Systems

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 82 SESAME Security System

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 83 Globus System Security Policy and Requirements -- Overview

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 84 Further Properties of Globus Entities

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 85 Globus Application Requirements

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 86 Relevant Components of Globus

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 87 Issues in the Globus Security Model

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 88 Elements of Globus Security Policy I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 89 Elements of Globus Security Policy II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 90 Globus Security Functional Requirements - I

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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 August 4 1997

Foil 91 Globus Security Functional Requirements - II

From Remarks on Java and Internet Security Web Certificate CPS616 Enhancement -- Summer 1997 . *
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
© 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 Apr 1 1998