Full HTML for Basic Basic Principles of Java and Internet Security

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 April 7 1998

Foil 5 Some General Issues II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 6 Need for Security in Commerce - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 7 Need for Security in Commerce - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 8 Structure of Internet and Security-I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 9 Structure of Internet and Security-II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 10 Structure of Internet and Security-III

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 11 A PKZIP Anecdote

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 12 Downloading Software is Dangerous?

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 13 The Moldavia Pornographic Phone Scam

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 14 An Early Netscape DNS Bug

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 15 Tempest and Control Zones

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 16 Military Security Levels

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 17 Firewalls and Gateways - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 18 Firewalls and Gateways II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 19 Encrypted Tunnels

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 20 The Great Clipper Controversy

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 21 Export Restrictions on Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 22 Denial of Service versus "Attacks"

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 23 Combining Denial of Service with more Malicious Attack

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 24 Comments on Denial of Service

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 25 Some Attacking Concepts

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 26 Naīve way Viruses Spread themselves

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 27 Introduction to Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 28 Breaking an Encryption Scheme

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 29 Types of Cryptographic Function

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 30 Security Uses of Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 31 Secret Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 32 Uses of Secret Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 33 Secret Key Authentication

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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.

Decrypt xA and see it gives rA

Encrypt rA to give xA

Encrypt rB to give xB

Decrypt xB and see it gives rB

HTML version of Basic Foils prepared April 7 1998

Foil 34 Message Integrity with Secret Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 35 Public Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 36 Insecure Link Transmission with Public Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 37 Authentication with public key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 38 Digital Signatures and Public Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 39 Use of Digital Signatures with public key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 40 Hash and Message Digests

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 41 Some Math Behind Secret Key Cryptography

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 42 Some Math behind RSA Algorithm -I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 43 Some Math behind RSA Algorithm -II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 44 Certificate Authorities

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 45 Review of Certificate Process

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

HTML version of Basic Foils prepared April 7 1998

Foil 46 Sample Certificate from Netscape

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

http://home.netscape.com/newsref/ref/netscape-test-ca.html

HTML version of Basic Foils prepared April 7 1998

Foil 47 VeriSign Digital ID's or Certificates - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 48 VeriSign Digital ID's or Certificates - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 49 VeriSign's Description of Digital ID's

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 50 VeriSign's Description of Certificate Revocation I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 51 VeriSign's Description of Certificate Revocation II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 52 The Java Security Model

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 53 Sandbox mechanism

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 54 What can applets do - I?

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 55 What can applets do - II?

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 56 What can applets do - III?

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 57 The Byte Code Verifier

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 58 Byte Code Verification

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 59 Why is type checking important!

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 60 Applet Class Loader

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 61 Secure Electronic Transaction SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 62 Electronic Shopping Experience - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 63 Electronic Shopping Experience - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 64 Features of SET - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 65 Features of SET - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 66 SET Encryption Summary

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

HTML version of Basic Foils prepared April 7 1998

Foil 67 Sample SET Cryptography Use

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 68 Sample SET Cryptography Steps 2 to 5

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 69 Sample SET Cryptography Step 6

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 70 Sample SET Cryptography Steps 7-10

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 71 Structure of Public Key System in SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 72 Features of Public Key System in SET - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 73 Features of Public Key System in SET - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 74 Cardholder Registration Process in SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 75 Merchant Registration Process in SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 76 Purchase Request Process in SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 77 Payment Authorization and Capture Processes in SET

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 78 SSL and S/MIME

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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)

http://home.netscape.com/assist/security/ssl/ (SSL Description)
http://home.netscape.com/assist/security/ssl/howitworks.html (RSA cryptography in SSL)
http://home.netscape.com/newsref/ref/internet-security.html (mainly SSL) and http://home.netscape.com/newsref/ref/rsa.html (A tutorial)
http://home.netscape.com/eng/ssl3/ssl-toc.html (SSL3.0 definition)
http://www.consensus.com/security/ssl-talk-faq.html (SSL FAQ and URL's)

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 April 7 1998

Foil 79 SSL from Netscape I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 80 SSL from Netscape II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 81 SSL from Netscape III

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 82 Netscape's Description of S/MIME

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 83 Generating Certificates on Unix-1

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 84 Generating Certificates on Unix-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 85 Sample Certificate and primary Key

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

HTML version of Basic Foils prepared April 7 1998

Foil 86 Secure Server Example-NPAC Grading System-1

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 87 Secure Server Example-NPAC Grading System-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 88 Secure Server Example-NPAC Grading System-3

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

Frustrated Evil People

The New Secure System:

HTML version of Basic Foils prepared April 7 1998

Foil 89 Secure Server Example-NPAC Grading System-4

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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://osprey7.npac.syr.edu:5557/grading.html

HTML version of Basic Foils prepared April 7 1998

Foil 90 Java Security Manager

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 91 Java Security Package

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 92 Java Digital Signatures-1

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 93 Java Digital Signatures-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 94 The Java Authentication Framework

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 95 The Java Authentication Framework-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 96 Generating Certificates in JDK

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

Full HTML Index

JDK comes with the javakey program.

"javakey" manages a database of identities and signers.

"javakey" provides generating and managing certificates.

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 April 7 1998

Foil 97 Generating Certificates in JDK-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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
- http://java.sun.com/security/signExample/
- See following foil for details

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 April 7 1998

Foil 98 Browsing Signed Applets

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 99 Some Other Security Systems

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 100 SESAME Security System

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 101 Details on SESAME I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 102 Details on SESAME II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 103 The GSS-API Security Interface

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 104 Globus System Security Policy and Requirements -- Overview

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 105 Further Properties of Globus Entities

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 106 Globus Application Requirements

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 107 Relevant Components of Globus

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 108 Issues in the Globus Security Model

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 109 Elements of Globus Security Policy I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 110 Elements of Globus Security Policy II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 111 Globus Security Functional Requirements - I

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 112 Globus Security Functional Requirements - II

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 113 JavaScript Security Model

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 114 JavaScript Security Issues

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 115 Same Origin Policy

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 116 Signed Script Policy-1

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 117 Signed Script Policy-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 118 Signed Script Policy-3

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 119 Codebase Principals-1

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 120 Codebase Principals-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 121 Scripts Signed by Different Principals

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 122 Principals of Windows and Layers

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 123 Determining Container Principals

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 124 Identifying Signed Scripts

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 125 Using Expanded Privileges

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 126 Targets

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 127 Targets-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 128 Importing and Exporting Functions

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 129 Weaknesses in the JavaScript Model

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 130 Signing Scripts

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 131 Signing Scripts-2

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 132 Signing Scripts-3

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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 April 7 1998

Foil 133 Signing Scripts-4

From Basic Principles of Java and Internet Security CPS616 Web Technologies -- Spring 98. *

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, zigbert visit the URL:

http://developer.netscape.com/docs/manuals/signedobj/signtool/index.htm

http://developer.netscape.com/docs/manuals/signedobj/zigbert/index.htm

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

Page produced by wwwfoil on Sun Nov 29 1998