Security Interests, Problems, and Options
Major Internet Security Technologies
Firewalls and Proxies Filter Messages
Encryption Protects Confidential Data
Digital Signatures Detect Tampering
Digital Certificates Authenticate Correspondents
SSL: Putting it All Together
Introducing the Castanet Product Family
BackChannels Protect User Data
Signed Channels Arrive Intact and Authenticated
Trusted Channels Can Do More
Transmitters Control Access
Secure Transmitters Encrypt and Authenticate
As businesses form closer relationships with customers and business partners, and as employee mobility grows, the Internet becomes an increasingly attractive medium for software distribution. MarimbaTM's first CastanetTM release made Internet software distribution practical. Castanet 2.0 gives software developers, distributors, and users the options they need to secure software distribution in accord with their requirements and preferences. It does so by adapting industry-standard technologies, originally developed to protect Web-based commerce, to the domain of Internet software distribution.
Like most aspects of the Internet, security is a dynamic field. Two Internet security measures, firewalls and proxies, hardly existed five years ago. Now they are standard protection for corporate networks connected to the Internet. Recently, other mechanisms--public key encryption, digital signatures, digital certificates, and SSL--have begun to be used to secure Web-based commerce. This paper describes these young security technologies and shows how Marimba has incorporated them into its Castanet 2.0 product family, leading the way to secure software distribution. The Castanet security facilities can be employed in combinations to satisfy a range of security needs--those that are recognized today, as well as those that, due to changing business conditions or new developments on the Internet, will be discovered tomorrow.
Whether software is distributed in stores, through the mail, or over the Internet, secure delivery is in the interest of developers, distributors, and users. For example, users want to know who wrote an application so they can estimate its quality and the availability of support now and in the future. In the retail store, customers examine the software box for the developer's identity, perhaps unconsciously aware that it's fairly difficult to counterfeit a box and get it into retail distribution. In-store customers also typically reject boxes whose broken shrinkwrap gives evidence of tampering.
When software is delivered over the Internet by ordinary means, it arrives without a shrinkwrapped box. It has also traveled over a medium that is less protected against counterfeiters and vandals than the retail store system or the mail. If the Internet is to become a distribution medium for more than shareware and demo software, it needs more options for protecting the interests of people and companies that create, distribute, and use software.
Some of their overlapping interests include:
Problems Real and Perceived
The Internet is an open communication medium. Openness is both its great
strength and its potential weakness. Not only can anyone attach a computer
to the Internet, but the Internet's routing scheme may send messages through
such a computer, giving its owner the opportunity for mischief. (All Internet
communication, including the transfer of software, is embodied in messages.)
Routing is the root of the Internet security problem for software distribution:
Unless the sender and receiver have a direct connection, the route of a
message cannot be controlled. A message may pass through multiple unknown
computers as it travels to its destination, and two messages addressed to
the same destination may travel different routes.
Potentially working against the interests of software developers, distributors, and users are thieves, vandals, and impostors. Internet thieves whose computers are positioned between a sender and receiver can undetectibly copy passing messages. Vandals can change bits in messages and pass them on. Impostors can pose as developers or distributors, supplying bogus and potentially harmful software.
Though the Internet is open to abuse, clearly a great deal of software is distributed over it by FTP (file transfer protocol, which Web browsers use to download software) with little evidence of interference. In part, that may be because theft on the Internet is very hard to detect. In part, it may be because stories of Internet security problems are underreported. In part, the value of the software that's currently distributed over the Internet may be too low to attract criminal interest.
Any of these factors may change as the Internet is increasingly used to distribute valuable proprietary software. Companies should be prepared for tomorrow's security problems, real or perceived, even if they believe that today's Internet environment does not justify security precautions. If the public comes to believe that unprotected Internet software distribution is unsafe, a company that depends on it will have to increase security very quickly. Prudent software developers and distributors will familiarize themselves with Internet security options before they are forced to.
One Size Doesn't Fit All
It's important to recognize that "one size doesn't fit all" in
either real world or Internet security measures. Anyone who visits many
companies notices how security practices vary among them. At a few, a visitor
may simply walk in. At others, sign-in and an escort are required. Some
companies demand proof of identity, and a few subject their visitors to
a search. Clearly no single visitor security practice fits all companies.
The same is true of Internet security. Most security threats posed by real world visitors have counterparts in the Internet: thieves, vandals, and impostors are at work in both realms. In the real world and the Internet world, a rational company identifies the potential threats and assesses:
The variables have different values in different companies, and in the same company at different times. A high level of protection that's justified at one company might be wasted at another. But companies change, their business environments change, and certainly the Internet changes. Companies distributing software over the Internet need an array of security choices that they can revisit from time to time to rebalance protection needs and costs.
Two forces have driven the development of Internet security technologies. The first can be likened to burglary: breaking into private networks attached to the Internet. Two closely related techniques have been developed to repel burglars, or crackers as they are commonly known: firewalls and proxies. The second force impelling the development of Internet security mechanisms is Internet commerce--doing business on the World Wide Web. For Internet commerce to achieve its potential, its customers and merchants must have at least as much confidence in the system as those who do business by mail. To secure Internet commerce, the industry uses encryption, digital signatures, digital certificates, and SSL (the Secure Sockets Layer protocol).
Recognizing that software distribution over the Internet has much in common with Internet commerce, Marimba has incorporated these technologies into its Castanet 2.0 product family. The following sections survey the technologies that are directly applicable to Internet software distribution, after first explaining the peripheral role of firewalls and proxies.
Firewalls and Proxies
Filter Messages
A firewall connects a private network to the Internet and filters messages
that pass from either network to the other. A firewall is a large-mesh filter;
it can refuse to pass a message based on the sender's address, the receiver's
address, or the message protocol (for example, telnet or FTP).
Proxies provide finer control than firewalls because each proxy understands an Internet protocol; for example, there are HTTP (Web browser) proxies and FTP proxies. As their name suggests, proxies also provide indirection. A browser inside the firewall connects to the HTTP proxy on the firewall; the proxy connects to the Web server outside the firewall, protecting the identity of the originating machine inside the firewall. Proxies also provide caching but that's a performance, not a security, feature.
How do proxies and firewalls help secure either Web commerce or software distribution? They don't. Their job is to help secure the private network from attack without severing the private network from the Internet altogether. They constitute a semi-permeable membrane between two networks. Different techniques are required to secure the data that firewalls and proxies allow through the membrane, and to mutually identify the sending and receiving parties on either side of it.
Encryption Protects
Confidential Data
Encryption is the foundation of secure message transmission in an open medium
like the Internet. To encrypt a message means to make it secret by scrambling
it. An encrypted message is useless gibberish to anyone who reads it; therefore
an encrypted message can be exposed without revealing its true content.
A message is encrypted with a fixed algorithm and a variable called a key. A key parameterizes an encryption algorithm so the algorithm doesn't have to be kept secret. Encrypting a message twice with the same algorithm and different keys is functionally equivalent to encrypting the message with two different algorithms. Longer keys are harder to guess than shorter ones and therefore make encrypted messages more secure. Encryption with keys longer than 40 bits is called "strong encryption."
There are two major families of encryption algorithms, symmetric key and public key (sometimes called asymmetric). Each approach has advantages that make it the best choice for some situations. SSL, described shortly, uses the best features of both symmetric and public key encryption.
Symmetric key encryption might be called shared key because the sender and receiver use the same key to encrypt and decrypt a message. Symmetric key encryption is fast but it does not scale well administratively. Every combination of sender and receiver must have its own shared key; creating, managing, and protecting a mushrooming collection of keys soon becomes an intractable problem. Nor is it easy for a sender and receiver to establish a symmetric key because the key must be sent through a secure channel: by courier or fax, for example.
Public key encryption uses two keys which are generated by software built into a product, for example, a Web browser or the Castanet Publisher and Transmitter. One key, which can be sent openly over an insecure channel such as the Internet, is called the public key. Its partner private key must be kept secret. In contrast to symmetric key encryption, the keys operate asymmetrically: A message encrypted with one key can only be decrypted with its counterpart key. In other words, a message encrypted with a private key can only be decrypted with the corresponding public key, and a message encrypted with a public key can only be decrypted with the corresponding private key.
Consider a software distribution example of public key encryption. Suppose Acme Widgets Corp. wants to send its supplier Fantastic Fasteners a proprietary program that lets Fantastic check Acme inventories. Fantastic and Acme both have public/private key pairs and each has the public key of the other (remember, only private keys must be guarded). Acme encrypts the program with Fantastic's public key and sends the encrypted program to Fantastic as an email attachment. Because of the asymmetric property of public/private keys, the attachment can only be decrypted by someone who has Fantastic's private key. So long as Fantastic guards its private key, the encrypted program will be transmitted to Fantastic in confidence. Internet snoops can look at the encrypted program but can't use it or understand it. Note that although this example illustrates one way of using public key encryption to transmit confidential information, assuring confidentiality is but one element of secure software distribution.
Public key encryption's advantages and disadvantages are the reverse of symmetric key encryption's. Public/private key pairs are easy to administer because each party uses a single key pair for all encrypted communication, and because public keys can be exchanged through unprotected channels, such as Internet email. But public key encryption and decryption are slow compared to the same operations done with symmetric keys.
Digital Signatures
Detect Tampering
A message sent over the Internet cannot be protected from alteration, but
alterations can be detected if the sender signs the message. Signing
adds a short encrypted value, called a digital signature, to the end of
the message. A message receiver can use the digital signature to learn whether
an incoming message is bit-for-bit identical to the message that was sent.
Suppose a prospective software user, for example, downloads a signed application
and discovers from its digital signature that the application has been altered
in transit. The user knows the corrupted software is not to be trusted and
should be discarded.
A digital signature is an encrypted message digest. A message digest is a fixed-length code (typically 128 bits) that, in effect, uniquely summarizes the contents of a message of any length. A good digest algorithm is fast, produces very different digests for slightly different messages, and never produces the same digest for different messages. Several message digest algorithms have been invented; two of the most widely used are MD5 from RSA Data Security, and SHA-1 from the U.S. government.
If a message sender appends a digest to a message, a message receiver can detect if the message (or the digest) has been altered in transmission. A receiver computes its own digest of the message, using the same digest algorithm; if the receiver's digest is identical to the sender's, the message has arrived intact. If a vandal makes a tiny change to the message, the digests will not compare equal. If a vandal substitutes a different message for the sender's, but keeps the sender's digest, the receiver will also detect the discrepancy. However, a vandal can fool a receiver by substituting a different message with a properly computed digest. That's why a digital signature is an encrypted message digest.
To produce a digital signature, a sender creates a message digest, then encrypts it with the sender's private key. The sender signs the message by appending the private-key-encrypted-digest. (Why doesn't the sender encrypt the entire message with its private key? Because the short digest can be encrypted so much faster. Note as well, that encrypting the full message does not increase security, because anyone with the sender's public key can decrypt the message.) A vandal cannot undetectibly modify a signed message because a vandal does not have the sender's private key--remember, private keys must be kept private. Any alteration of the message invalidates the sender's attached (encrypted) digest. Altering the message, then computing a correct digest and encrypting it with the vandal's private key won't work either, because receiver uses the sender's public key to decrypt the signature.
To verify the integrity of a signed incoming message, a receiver must know the digest algorithm used by the sender, and must have a copy of the sender's public key. Suppose, for example, that a receiver has downloaded a signed application. To determine whether the application was damaged in transit, the receiver:
The receiver of a signed message can detect whether the message is intact or has been corrupted. But how does the receiver reliably obtain the sender's public key? In other words, what prevents the following scenario:
A prudent receiver will refuse to believe a signed message unless it is accompanied by a digital certificate.
Digital Certificates
Authenticate Correspondents
Digital certificates are used to detect impostors on the Internet. A digital
certificate is an unforgeable data structure that attests to the binding
of a subject (person or company) and a public key. In other words, a certificate
says "The public key shown in this certificate really belongs to the
subject named in this certificate." By implication, a certificate also
says "The private key partner of the public key shown in this certificate
also belongs to the subject named in this certificate." A certificate's
reliable binding subject and key pair means this:
If a receiver can correctly decrypt a message with the public key listed in a certificate, the encryptor of that message must be the subject named in the certificate.
Note once again that this statement is true so long as the certificate subject safeguards its private key.
Here's how a certificate can be used to authenticate a message sender. Suppose Fantastic Fasteners receives a message that says "This message is from Acme Widgets. We'd like to send you a program. Here is our digital certificate containing our public key." To learn whether the sender is in fact Acme Widgets or someone who has sent Acme's certificate, Fantastic Fasteners:
An impostor cannot successfully pose as Acme Widgets because he or she cannot obtain a false digital certificate from a reputable certificate authority (CA). Nor, as will be shown, can an impostor undetectibly forge a certificate. A certificate authority is a trusted third party that attests to the ownership of public keys. To obtain a certificate, an applicant presents proof of identity and a public key to a certificate authority. After verifying the applicant's identity, the CA issues a certificate signed with the CA's private key. A digital certificate is as trustworthy as the certificate authority that issued it. Each country has just a handful of certificate authorities to simplify the job of monitoring their integrity and competence.
Most digital certificates follow the format prescribed by the X.509 version 3 standard, which defines these main fields:
A certificate is itself a signed message; it is signed with the issuing CA's private key. Because CA public keys are well-known, a receiver can verify a digital certificate's integrity in the usual way. The receiver applies the certificate's digest algorithm to the certificate data, uses the CA's public key to decrypt its signature into a message digest, and compares the two digests. If they match, the receiver knows:
A certificate authority may provide several types of certificates, each type certifying a different level of identity checking. For example, a certificate for individuals is typically inexpensive and minimally researched. A server (host machine) certificate is more thoroughly researched and more expensive. An applicant for a software-signing certificate is yet more carefully checked.
Digital certificates expire automatically and can be revoked by CAs. Automatic expiration gives the CA the opportunity to reinvestigate a certificate's subject, and limits the time available for guessing the private key that goes with a certificate's public key. Revocation limits the damage an impostor can do with a certificate and a stolen private key that goes with it. Software that receives a certificate can look up the certificate serial number in a certificate revocation list--the analog of checking a credit card against a list of stolen cards.
SSL: Putting it All Together
SSL is the Secure Sockets Layer protocol invented by Netscape Communications
Corporation and adopted as the industry standard for Web-browser-based Internet
commerce. However, SSL can be used by any Internet protocol; it's really
a generic way to secure communication between Internet clients and servers.
SSL uses encryption, message digests, and certificates, which themselves employ digital signatures. SSL client software is pre-loaded with the certificates of certificate authorities the client software developer trusts; the software may also allow its users to add more certificates. The first phase of an SSL connection is called the handshake, and is conducted in the clear, that is, without encryption. When a client contacts an SSL server, the server returns its certificate. If the client accepts the certificate, the client and server negotiate a symmetric key encryption algorithm. The client then chooses a symmetric key, encrypts it with the server's public key (obtained from the server's certificate), and sends it to the server. In short, the handshake establishes the client's trust of the server, and uses slow public key encryption to deliver a symmetric key. Fast symmetric key encryption is used to protect the messages transmitted in the remainder of the connection. The encrypted messages carry digests which each side checks to be sure the messages have not been altered in transmission.
An SSL server must present a certificate to its clients--must authenticate itself. An SSL server may require a client to authenticate itself, either by presenting a certificate, or by a conventional user ID and password. Client authentication by password is more common at present because comparatively few users have obtained certificates.
Although SSL blends multiple security technologies, bear in mind that digital certificates and digital signatures are useful with encrypted and unencrypted messages. In other words, the concepts of authentication and integrity are logically distinct from the concept of confidentiality. Consider software distribution as an example. In some situations, protection from eavesdropping is unimportant, but file integrity and vendor authentication are critical. Such situations are best served by signing the downloaded files and sending a code-signing certificate with them; there's no need to incur the performance cost of encryption.
The Castanet system exists to simplify the distribution, installation, and updating of software over intranets and the Internet. Because the Internet is not inherently secure, Castanet 2.0 uses the proven technologies described in the previous section to provide an array of security facilities. Software developers and distributors can employ the facilities that match their security needs, ensuring that software distributed with Castanet is:
Although the underlying technologies employed by Castanet are complex, the Castanet security user interfaces are simple enough to convince users and administrators that security measures are features, not burdens.
The Castanet 2.0 software incorporates encryption libraries developed by RSA Data Security.The principal Castanet family members are:
Auxiliary Castanet family products include the Gateway, the Proxy, and Tuner Administrator; they don't have security roles. The array of security features provided by the Tuner and UpdateNow products is called the Castanet SecureTM facility.
BackChannels Protect
User Data
Although a Tuner's main function is to download channels from Transmitters,
a channel can direct a Tuner to return data to the channel's Transmitter.
This channel feedback mechanism is called the BackChannelTM
feature. The format and content of a channel's BackChannel data are chosen
by the channel developer. Typical BackChannel data are user preference and
behavior records; for example, the user's language and the channel features
he or she has used. The Tuner sends a channel's accumulated BackChannel
data when it checks the Transmitter for updates to the channel. If a channel
has been downloaded from a secure Transmitter
(described shortly), the Tuner sends the channel's BackChannel data in an
SSL connection to protect the data from eavesdroppers. The BackChannel feature
is discretionary; users who do not wish to reveal information to Transmitters
may disable it.
BackChannel data is most useful when it's fed to an optional channel component, called a plugin, that runs on a Transmitter. If a channel has no plugin, the Transmitter records the channel's BackChannel data in a per-channel directory. If a channel has a plugin, the Transmitter invokes the plugin when it receives BackChannel data from a corresponding channel, passing the data in the call. A plugin can use BackChannel data to personalize channels on a per-user basis by selecting files for the Transmitter to return each channel. For example, a plugin can select files written in the user's language or advertisements related to those the user has clicked since the previous channel update. If the plugin is running on a secure Transmitter, the files will be transmitted under the protection of SSL encryption.
Signed Channels Arrive
Intact and Authenticated
To ensure channel users of the developer's identity and the bit-for-bit
integrity of a channel, a developer can add a digital signature and a certificate
to a channel by directing the Castanet Publisher to sign the channel.
Both are downloaded with the channel to Tuners.
To sign channels, a development organization needs a channel-signing certificate from VeriSign Corporation. The Castanet Publisher includes a complete certificate management facility that:
When the Tuner receives a signed channel from a Transmitter, it validates the attached channel-signing certificate and the digital signature. The Tuner uses a pre-loaded VeriSign root certificate to validate the channel certificate. A user can inspect a signed channel's certificate (see figure) at any time.
To verify a signed channel's signature, the Tuner decrypts the signature with the public key in the developer's validated certificate. Decryption yields the message digest that the Castanet Publisher computed over the channel's files--unless an impostor has appropriated someone else's certificate. In that case, the impostor will have signed the channel with a private key that doesn't match the public key in the certificate; therefore, decrypting the signature will produce a corrupted digest. The Tuner then computes its own digest over the files it received, and compares its digest to the Publishers. If the digests agree, the channel has been received intact from the developer named in the certificate; the Tuner installs the channel and distinguishes it from ordinary channels with a pen icon. If the digests disagree, either the channel was damaged in transit, or it was signed by an impostor; in that case, the Tuner displays an error message and discards the channel files. In addition to verifying signed channels when they are received, the Tuner reverifies a channel after receiving an update. And to ensure that a signed channel has not been corrupted on the user's disk, the Tuner reverifies the channel's digest before it launching it. A user can launch a signed channel with the same confidence that he or she launches a shrinkwrapped application bought in a store.
Personalizing plugins might appear to conflict with signed channels. If a plugin changes a file in a signed channel, the change invalidates the channel message digest previously computed by the Publisher. To circumvent this problem, the Publisher offers partial channel signing. To partially sign a channel, a developer designates a directory (folder) containing the files to be signed--those that the channel's plugin will not alter. Typically, these are code files, but there's no restriction on their content. The channel's plugin is free to modify, add, or delete files--typically data files--that are outside of the signed directory. Because the channel's digital signature covers only the unchanging files in the signed directory, changes to other files don't invalidate the digest, which the Tuner recomputes when it receives channel updates.
Trusted Channels
Can Do More
Castanet channels can be either untrusted or trusted. Untrusted channels
are prevented from performing potentially dangerous operations such
as writing over a user file. The Castanet system's trusted channel facility
lets a developer nominate a channel for trusted status--meaning it runs
without constraint--but reserves to users the right to confirm the nomination.
In general, users will not trust channels from unknown developers and will
trust those that are from developers they trust. In short, users can make
the tradeoff between channel safety and channel power.
Castanet channels are written in Java, optionally supplemented by a native language such as C or C++. Channels run under control of the Tuner security manager, which is specialization of the Java applet security manager. By default, the Tuner security manager considers a channel to be untrusted, and prohibits these potentially harmful operations:
As a result, users can download a Java channel written by an unknown developer without worrying that the channel will damage or reveal information.
Some channels need to perform operations that the Tuner security manager denies to untrusted channels. For example, a scheduling channel may need to connect to machines on the local network to check the schedules of colleagues invited to a meeting. Or a financial analysis channel may need to execute a compute-intensive algorithm that's written in C. A developer who creates a channel that needs capabilities that are denied to untrusted channels can direct the Publisher to designate the channel as trusted. A channel that's designated as trusted must be signed to ensure its integrity and to reliably inform prospective users of the channel developer's identity.
Designating a channel as trusted in the Publisher nominates the channel for trusted status, but only channel users can make a channel trusted in fact. They do so primarily by inspecting the certificate that comes with a trusted channel; if they trust the channel developer named in the certificate, they are likely to trust the developer's channel.
When the Tuner downloads a channel that's designated as trusted, it does not immediately launch the channel. Instead, it:
The Tuner will not launch the channel until the user agrees to trust it. A user can revoke a channel's trusted status at any time. To remind users that they have trusted a channel, the Tuner marks it with a yellow cautionary icon as well as the pen icon that designates a signed channel.
Transmitters Control Access
Transmitters provide two ways to prevent unauthorized persons from downloading
sensitive channels. The first is the simplest. A channel developer can direct
the Publisher to designate a channel as hidden. Transmitters do not
display hidden channels. To download a hidden channel, a user must know
the channel's name and the Transmitter's name.
The Transmitter Access Control feature takes a more active approach to authorizing users: It asks prospective users for an ID and a password before displaying the channels it serves. Access Control should not be construed as a bullet-proof user authentication facility. An access-controlled Transmitter protects its channels in the same way, and to the same degree, that an access-controlled Web server protects its pages.
Transmitter administrators can create and maintain the list of user IDs and passwords with a graphical editor that's built into the Transmitter. Alternatively, they can import an existing user ID/password file that's stored in the LDIF format, which is produced by Lightweight Directory Access Protocol (LDAP) implementations.
Secure Transmitters
Encrypt and Authenticate
Signed channels assure channel integrity and developer authenticity, two
of the three main security concerns. Secure Transmitters solve the third
security problem, confidentiality, by conducting all communications with
Publishers and Tuners under the protection of SSL. That means that channel
files are encrypted when they are published, when they are downloaded, and
when they are updated. BackChannel data sent to a secure Transmitter is
also encrypted. Any data that an eavesdropper intercepts from a secure Transmitter
is therefore useless gibberish.
To assure Tuner and Publisher users that they have connected with the machine they intended, and not an impostor using the same host name, secure Transmitters authenticate themselves with digital certificates. The Transmitter includes an easy-to-use facility that guides an administrator through acquisition and installation of a VeriSign certificate. The Transmitter generates the public/private key pair and protects the private key by encrypting it with an administrator-provided password. A secure Transmitter will not start unless this password is supplied.
The Castanet 2.0 software distribution system includes an array of security features that companies can selectively engage to protect their businesses, their software, and their customers and partners. By choosing Castanet for software distribution, they are also positioned to respond immediately to new security requirements, whether caused by changing business conditions, altered public perceptions, or the ever-evolving Internet.
© Copyright 1997 Marimba, Inc. All rights reserved. Marimba, the Marimba logo, Castanet, UpdateNow, FileBroker, Castanet Secure, BackChannel are trademarks of Marimba, Inc. All other brand and product names are trademarks of their respective companies.