Solved

Difference between signed and unsigned applets.

Posted on 1999-01-06
5
2,248 Views
Last Modified: 2013-11-23
I would like to know the difference between signed and unsigned applets.
0
Comment
Question by:WaelEg
  • 2
  • 2
5 Comments
 
LVL 13

Accepted Solution

by:
Mirkwood earned 50 total points
ID: 1230485
Trusted Versus Untrusted Classes
J/Direct divides all loaded Java classes into one of two categories:

Fully trusted (indicating maximum permissions).


Untrusted.
Only fully trusted classes are allowed to use J/Direct. A Java class is considered fully trusted if one of the following statements is true:

The class is digitally signed indicating full trust. An example of such a class would be a signed applet.


The class is installed on the target computer's CLASSPATH or installed by the package manager. A downloadable, digitally signed library designed to be shared among multiple applets could meet this criterion.


The class is running as a non-browser application using the JVIEW or the WJVIEW application.
An unsigned applet on the Web, on the other hand, constitutes untrusted Java code.

0
 

Author Comment

by:WaelEg
ID: 1230486
Thanks for your answers but some expressions I didn't understand like J/Direct, JVIEW and WJVIEW also who are judge the trusted and non-trusted aspects of the applet and what is the difference from programmers point of view?
0
 
LVL 13

Expert Comment

by:Mirkwood
ID: 1230487


Cabinet File Permission Levels

A Brief Introduction to Zones

Using Signcode with Java Permission Information

How to Sign a Cabinet File with Java Permissions
 
           
Signing a Cabinet File     Previous Tools Next

 
 



Signing a Cabinet File with Java Permissions Using Signcode

Overview
Signing a cabinet file with Java permissions gives developers more detailed control over the security restrictions placed on their applet when it is used over the Internet or an intranet.

While encoding permissions inside an applet is optional, it provides several additional benefits over regular signing:

Applets and controls can be granted only specific permissions they need.  If an applet is signed in the old style (without Java information), the user must choose between running it in the Java "sandbox," or allowing it to be fully trusted. For example, permission signing enables applets to request permission to store only temporary files on the client hard disk. Users of a permission signed applet can allow the it to run, without worrying that it will have full access to their system.  
Fewer dialog boxes are presented to the user.  When Microsoft® Internet Explorer zones are used, applets might automatically receive some permissions when they are downloaded from a certain zone. When an applet is signed with the specific permissions it needs, the user will not even be queried if the zone automatically grants the permissions that the applet needs.  


Cabinet File Permission Levels
The signcode utility enables you to sign a cabinet file at three different security levels. They are as follows:

High  The High security level ensures that all Java code contained in the cabinet file will run in the Java "sandbox." High is the most stringent level of signing, and is equivalent to the same permissions that an unsigned applet is granted. Signing a cabinet file with High ensures that it will never be able to do more than it would in the sandbox, regardless of where the code comes from and what the user allows it to do. A cabinet file signed High will always be allowed to run without any user intervention.  
Medium  The Medium security level places the same restrictions on the applet as High, but with a few exceptions. Applets signed with the Medium level request user-directed file I/O as well as the ability to store 1 MB of data in the client computer's scratch space. This storage can be accessed through the com.ms.io.clientstorage API. Applets signed with Medium permissions may also call user-directed file I/O routines. These routines will present dialogs to the user and ensure that all file operations are done with user intervention. A cabinet file signed Medium will run without intervention in Low and Medium security zones. Because the requested permissions are greater than a High security zone can automatically give, a Medium signed cabinet file will prompt the user before allowing code to run in a High security zone.  
Low  The Low security level means the code in the cabinet file is requesting to be fully trusted. Only a zone set at Low security can grant this much access without first asking the user. The other two zones prompt the user before running the applet.  


Cabinet Files and ActiveX
Cabinet files may contain both Microsoft® ActiveX® Controls and Java code when downloaded using the uselibrary parameter. Because ActiveX controls must be fully trusted to run, they are treated differently from Java code. The previous security levels apply only to Java code, and ActiveX controls in the cabinet file will not be allowed to run.

For ActiveX controls to run when they are in a cabinet file that uses Java Permission signing, you must specify that the cabinet file contain ActiveX controls in the signature. Do so by specifying the LowX, MediumX, or HighX flags instead of Low, Medium, or High. These three flags have the same meaning as their respective flags without the X. However, if you include ActiveX controls in the cabinet file, they will be denied, allowed to run, or will query the user, based on the security settings of the zone.

Note If your cabinet file has only ActiveX controls, do not use the Java signing method. Instead, use signcode without JavaSign.dll.

A Brief Introduction to Zones
Zones are a way of reducing the complexity of system security by assigning security policies to entire groups of sites.

Microsoft® Internet Explorer 4.0 divides your Internet world into zones, so you can assign specific security settings to each zone, and then assign Web sites to a zone with a suitable security level. The name of the current zone appears on a status bar in the lower-right corner. Whenever you attempt to open or download content from the Web, Internet Explorer checks the security settings for that Web site's zone. Internet Explorer provides four zones:

Corporate Intranet  Addresses that don't require a proxy server (those listed in the Proxy Settings as not requiring a proxy server). The addresses included in this zone are defined by the system administrator in the Internet Explorer Administrator's Kit (IEAK). The default security level for the Corporate Intranet zone is Low.  
Trusted Sites  Sites you trust enough to require low security before downloading or running files from the Internet. You can assign sites to this zone. By default, the security level for the Trusted Sites zone is Low.  
Restricted Sites  Sites you don't trust, requiring medium or high security before downloading or running files from the Internet. You can assign sites to this zone. By default, the security level for the Restricted Sites zone is High.  
Internet  By default, the Internet is anything not on your computer, the Intranet, or assigned to any other zone. The default security level for the Internet zone is Medium.  


Each zone can be set to a specific security level. The security level applies to all code downloaded from sites within the zone:

High Security  Java applets will run in the sandbox without intervention from the user. Any requests beyond the sandbox will query the user. ActiveX controls will never be allowed to run.  
Medium Security  A zone set for Medium Security will allow applets to have up to 1 MB of scratch space on the client computer, if it is requested in the cabinet file signature. Any requests beyond those restrictions will cause the user to be queried. Applets signed with Medium permissions may also call user-directed file I/O routines. These routines will present dialogs to the user and ensure that all file operations are done with user intervention. ActiveX controls will also prompt the user before running.  
Low Security  A zone set for Low Security will allow applets to run fully trusted, if they request to do so in their signature. ActiveX controls will prompt the user before running.  
Custom  The user or the administrator defines Custom Security levels. They may also allow ActiveX Controls to run without prompting, whereas the predefined zones do not have that option.  


For more information on how zones are configured and used, see the online Help for Internet Explorer.

How Cabinet File Signing Works with Internet Explorer Zones
When a signed cabinet file is downloaded from a page, the signature is examined to see if it contains permission information. If so, Internet Explorer and the Microsoft VM for Java work together to determine what the applet will be allowed to do. This determination is based on the security level of the Zone the cabinet file is downloaded from, the permissions requested in the cabinet signature, and the response of the user, if needed.

If a cabinet file is signed at a certain security level, it will be allowed to run with that level of permissions without any intervention from the user, but only if the Zone is set at that same level or less secure. However, if a cabinet file is requesting permissions greater than those that can be automatically granted by a zone, the user is presented with a query. If the user agrees to let the applet run, it is run with the signed permissions. Otherwise, the applet will not be allowed to run.

The following chart details this behavior.

Cabinet files signed with this level    High  Medium  Low  
Zone  High  Runs in High Query (Yes = Medium)  Query (Yes = Low)  
Level  Medium  Runs in High Runs in Medium  Query (Yes = Low)  
 Low  Runs in High Runs in Medium  Runs in Low  


If the user is presented with a query and denies the request, the applet will not run.

Using Signcode with Java Permission Information
To add the Java permission information into the signature, use the -j JavaSign.dll option to signcode. You may also specify the -jp option for finer control over the exact permissions in the signature.

The command line for signcode with the Java permission information is as follows:

signcode [options] -j JavaSign.dll [-jp level] [more options]

-j JavaSign.dll  The option that tells signcode to use Java permission information.


 
-jp level  Level is an optional string that tells what level of permissions to encode in the cabinet file. This string must appear immediately after the -j parameter. You can use any of the flags shown in the following table.

Low  Medium  High  
   
LowX  MediumX  HighX  

If this option is not specified, a default level of LowX will be used. These exact permissions associated with these flags are described in Cabinet File Permission Levels and Cabinet Files and ActiveX.

If the string is not one of the six predefined levels, it is accepted as the name of an .INI file that specifies the permissions to encode. You can create this .INI file by hand, following the example provided by the sample permissions .INI file, or you can use the piniedit tool to generate the .INI file for you. The following example shows a section of a sample permissions .INI file that you can use to specify special permissions.


;
; ClientStoragePermission
;
[com.ms.security.permissions.ClientStoragePermission]
; Limit is in bytes
Limit=100
RoamingFiles=true
GlobalExempt=true

;
; ThreadPermission
;
[com.ms.security.permissions.ThreadPermission]
AllThreadGroups=true
AllThreads=true
The ClientStoragePermission class represents a permission for controlling access to client-side storage that is available through the ClientStore class. The ThreadPermission class represents a permission that controls the ability to create and manipulate threads and thread groups. For more information on these and other permissions, see the com.ms.security.permissions package.
 

Using the Chkjava Utility
To examine the permission information in a signed cabinet file, run

chkjava filename
where filename is the name of the filename to verify.

How to Sign a Cabinet File with Java Permissions
The following steps show you how to sign a cabinet file with Java permissions.

First, create a certificate with the MakeCert program.
C:\..\>makecert -sk MyKeyName -n "CN=My Publisher Name" MyTestCert.cer

Turn your certificate into a test Software Publisher Certificate (SPC). A valid SPC is obtained from a Certification Authority.
C:\..\>cert2spc MyTestCert.cer MyTestCert.spc

Sign the cabinet file with the permissions. The following command line signs MyApplet.CAB with medium permissions, using the key and certificate created previously.
C:\..\>signcode -j javasign.dll -jp medium -spc MyTestCert.spc
   -k MyKeyName MyApplet.cab


Verify that the appropriate permissions have been correctly encoded in the file.
C:\..\>chkjava MyApplet.cab

More Information
For more information on all of the parameters for makecert, cert2spc, signcode, and chktrust, see the Microsoft SDK for Java Tools quick reference section.

For more information on how zones are configured and used, see the online help for Internet Explorer.

 



0
 
LVL 16

Expert Comment

by:heyhey_
ID: 1230488
>> I would like to know the difference between signed and unsigned applets.

ordinary applets are unsigned applets.
they are not allowed to perform some actions on the client computer - for example
- write to the local file system
- connect to differnet server that their originator
- know on what computer they work

signed applets are digitally signed applets that the and user can trust (if he trust the person / organization that have signed them) so these applets can have more functionality implemented. (of course signed applet will work only if the end user declares that he trusts this applet)

Generally by applets we mean unsigned applets - that are pieces of code that are executed on the client machine. Java (unsigned) Applets are much more safe than ActiveX controls - they can't damage the client computer.

Different browsers (IE, NN, HotJava) support different technologies for signing applets ... :(( (all of them based on public / private keys I think)

and signing applets (and applet security) is NOT connected with Microsoft  at all !!!
you'd better check JavaSoft notes on this technology ...

http://www.javasoft.com/sfaq/index.html
http://www.javasoft.com/products/jdk/1.0.2/changes.html
http://www.javasoft.com/security/codesign/index.html
http://www.javasoft.com/docs/books/tutorial/security1.1/index.html

best regards
  heyhey
0
 
LVL 16

Expert Comment

by:heyhey_
ID: 1230489
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

An old method to applying the Singleton pattern in your Java code is to check if a static instance, defined in the same class that needs to be instantiated once and only once, is null and then create a new instance; otherwise, the pre-existing insta…
By the end of 1980s, object oriented programming using languages like C++, Simula69 and ObjectPascal gained momentum. It looked like programmers finally found the perfect language. C++ successfully combined the object oriented principles of Simula w…
Viewers learn about the “while” loop and how to utilize it correctly in Java. Additionally, viewers begin exploring how to include conditional statements within a while loop and avoid an endless loop. Define While Loop: Basic Example: Explanatio…
Viewers will learn about basic arrays, how to declare them, and how to use them. Introduction and definition: Declare an array and cover the syntax of declaring them: Initialize every index in the created array: Example/Features of a basic arr…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now