|
|
|
By Martin Heller
Click Here to see a
35.1KB bitmap image of artwork
which goes with this article, entitled:
Java in a .GIFfy
SOMETIMES I COME up with pretty good ideas. Like the time I first saw the original Radius Full-Page Display, and asked if there wasn't some way to make it pivot from portrait to landscape mode. Or the time I told the Microsoft C++ group that starting and maintaining MFC projects by hand was too grungy for mere mortals, and suggested using "wizards" in Visual C++. I almost never get paid for these ideas, and I suspect the idea I'm toying with now won't make me any money, either. Ah, well, money isn't everything.
Here's the problem: Microsoft wants ActiveX Controls to be objects anyone can download from the Internet and use freely. But the people who write the controls want to be paid for their work. One obvious solution is for Microsoft to pay people outright for writing ActiveX Controls, and that's happening to a limited extent. But Microsoft can't, won't and shouldn't pay everyone who writes controls. Some controls are too proprietary or valuable to sell off to Microsoft, others compete with Microsoft-written or -sponsored controls, and yet others are just crap that no one should pay for.
Another obvious solution is to limit the controls' use. But the big question remains: How do you stop the pirates without inconveniencing legitimate users? At the Internet Professional Developers Conference in March, Microsoft's speakers skirted the issue. At April's Tech Ed trade show, I was convinced after speaking with vendors that none of them had a clue how to do it. As I conveyed this to WINDOWS Magazine's Dave Methvin over greasy pastries in the L.A. Convention Center, it hit me how the whole thing could work.
Vendors protect VBX and OLE Controls via a license file. When the file is properly installed on a system, the control can be used in a development environment. Without the license file, the control functions only as a runtime object.
The drawback of putting controls into HTML documents-at least as I saw things at the time-is that you don't need a development environment to author with them. HTML is self-documenting and always available for inspection. If you use an ActiveX Control on a Web page and I view the page, I'll have everything I need to put the control on one of my own Web pages, license file or no license file.
So what's the solution? Authenticate the parameters used to instantiate the control. You can pass an authentication code as an additional parameter, and it should be computable from the other parameters and some key in a heavily encrypted manner. The authentication can be as simple as an encrypted checksum or cyclic redundancy code of the data, or as complicated as an encrypted hash of the data that is then digitally signed.
You need two more pieces to make authentication useful for protecting controls. You must use the control to generate the authentication code in the development environment, and you need to require that the license file be present for authentication-code generation. With all three pieces in place, you do need a license file to author HTML pages that use the control; the control's original developer can continue selling the product to other developers, and end users are not inconvenienced.
You could come up with lots of refinements to a scheme like this. The license file or the parameters could include an expiration date, again protected from tampering by the authentication code. One of the authenticated parameters could be the URL of the Web page hosting the control; another could be the Web server's IP address, or a specific client network's IP address and mask. In addition, you could provide the license file, updates of the control and the control's help file on a secure Web server. This would make breaking the control's security scheme for development much harder and more expensive than simply buying the control.
To compute the authentication code, concatenate all the parameter strings, and pass that string plus some key strings or long integer seeds to an encrypted checksum, encrypted cyclic redundancy checking (CRC) or encrypted hash engine. You could compute the checksum or CRC with the same sort of algorithm used to validate packet transfers over a network or over serial communications protocols such as Kermit or Zmodem. Either the string encryption prior to checksum computation or the final checksum encryption could use any reasonably strong encryption algorithm. DES, the symmetric block-cipher algorithm banks use for electronic currency transmission, would be more than adequate. A simple XOR algorithm would probably be too weak to protect the control for long.
In ActiveX controls, there's more to the licensing scheme than meets the eye. A little-known token-passing scheme verifies at instantiation time that a licensed development environment has placed a control in a container. I don't have much in the way of details, apparently because Microsoft doesn't want to tell crackers where to look for the tokens. On the other hand, there's nothing stopping control vendors from implementing my authentication scheme, either instead of or in addition to Microsoft's licensing scheme. For that matter, Microsoft is supplying just the tools you'd need to implement my scheme effectively.
Microsoft provides strong RSA hash and digital signature algorithms in the Cryptographic Application Program Interface (CryptoAPI) to be included with Windows NT 4.0 and a future version of Windows 95. So, you may not need to waste space in the control for an encryption routine if you're willing to limit your audience to these new operating-system versions.
In the CryptoAPI scheme of things, your program starts an encryption session by getting the handle to a cryptographic service provider using CryptAcquireContext. The default or base provider is Microsoft's implementation of RSA Data Security's public-key encryption methods. These use the RSA algorithm for key exchange and digital signature, the RC2 or RC4 algorithms for encryption and the MD5 or SHA algorithms for hashing. RSA, RC2 and RC4 are all ciphers. RSA is a reasonably strong but computationally intense public-key cipher, RC2 is a 64-bit symmetric block cipher and RC4 is a symmetric stream cipher. Both MD5 and SHA produce hash values from a data block, MD5 a 128-bit and SHA a 160-bit.
To generate a unique hash code from a data block, first create a hash object using CryptCreateHash, and then generate the hash with CryptHashData. Next, validate an existing digital signature against the hash object and its public key using CryptVerifySignature, or create a new digital signature using CryptSignHash and your private key. You always sign hash codes and never data, because the public-key digital signature algorithms are so slow. Finally, to clean up, destroy the key used and the hash object, and release the provider handle.
If you'd rather do your own encrypted checksum, you can find working source code for the DES algorithm in many books and at several ftp sites. My personal favorites are Numerical Recipes in C (Cambridge Univ. Press) and the Lucifer source code found at any of the mirrors for the old Simtel 20 ftp site.
One hitch: Exporting encryption software from the U.S. requires a license, and the penalties for doing so without one can be significant. But if you're only doing signature validation and not enabling the end user to encrypt data, you should be able to get a license.
On that tepid note, I'd like to move on to my favorite source of heat and hype, the Java language. Microsoft is incorporating Java runtimes into Internet Explorer 3.0, which is free for the downloading. This means Java is becoming incorporated into Windows 95 and Windows NT, so it's fair game for a Programming Windows column. In addition-and perhaps more significantly for now-Java is already part of Netscape Navigator, the most prevalent Web browser.
Java's syntax is mostly based on C++ (see my review of Symantec Café in the July issue, Café Brews Hot Java Applications), and its standard class library reminds me of Smalltalk's. Java source is compiled to byte codes in the development environment, and is interpreted or compiled "just in time" on the client machine. It offers several compelling advantages over C++ for use in Web pages. For one, the applets are quite small, so they download quickly. And because Java byte code is system-independent, you don't have to post multiple versions. Finally, the Java class library is very complete and easy to use for most things you'd want to do on a Web page.
Like ActiveX Controls, Java applets can run on a client machine in the display context of a Web page, and a Java-aware browser will download them on demand. Java applets are invoked from HTML using the applet tag (applet code=Draw- Test.class width=400 height =400 /applet).
Java development tools, just-in-time compilers and third-party class libraries are still few and far between, but that's changing rapidly. There's no lack of books on Java programming, but are any of them actually useful? If I find any, I'll let you know. Meanwhile, I thought you might like a brief introduction to Java from the Olde Language Junkie.
Java is basically a variation on C++. Most of what you know about C++ will work as Java code, except for preprocessing, pointers and multiple inheritance. Instead of a preprocessor, Java has an import statement that adds an external package or type to a Java program's name space. Java packages, which use hierarchical names, are a way of organizing Java source code. An asterisk in an import statement's package specification asks for the package components to be imported on demand. So, import java.awt.* imports only the needed public classes from the Java Advanced Window Toolkit package hierarchy into an application, while importjava. util.Vector unconditionally imports the public Vector class from the java.util package. The package statement defines the classes' place in the hierarchy. The Java source for Vector includes the statement package java.util before the declaration public class Vector implements Cloneable.
Java source code has the .java extension, and Java-compiled byte code has the .class extension. You'll notice you need long filenames to support these naming conventions. To alleviate that problem and save space, you can keep classes in .ZIP files. The CLASSPATH environment variable specifies where Java is to find its classes; other environment variables specify the location of the Java directory tree for development.
Instead of multiple inheritance, Java has interfaces with implementations. The Vector class implements the Cloneable interface, for instance. The Cloneable interface extends Object, meaning it's derived from the default universal base class. Java classes may implement multiple interfaces, and Java interfaces may extend one or more other interfaces, but Java classes may only extend a single immediate superclass.
Java classes contain fields, which are variables and methods. Fields may be public, protected or private. Methods may be declared static, in which case they operate on the class; or not, in which case they operate on instances of the class. Methods may be abstract, final, native or synchronized. Abstract methods, which occur within abstract classes, have no implementation; all non-abstract-derived classes must implement the methods. Final methods may not be overwritten.
Native methods are implemented in some language other than Java, typically C or assembly language. Synchronized methods acquire a monitor lock on their instance before they execute-only one thread at a time can use a synchronized object. Synchronization among threads can also be done manually using the synchronized statement, which causes a statement to wait for a lock on an object before running. You can catch exceptions with try/Catches/Finally blocks.
If you're starting to think Java is a pretty sophisticated language despite the toy-like nature of most of the Java applets floating around on the Web, welcome to the club. I haven't even touched on the elegance and power of some of the Sun Java classes, the event model for applets or some of the odder parts of the Java hierarchy, such as layout managers.
In fact, Java's designers had a lot of ideas, and quite a few of them look good. I think I'd like those guys.
Contact Senior Contributing Editor Martin Heller at his Web page at http://www.winmag.com/people/mheller, via e-mail at mheller@cmp.com. To find his E-Mail ID Click Here
|
|
|