[ISN] The Keys to Security

From: mea culpa (jerichoat_private)
Date: Thu Sep 10 1998 - 02:50:36 PDT

  • Next message: mea culpa: "[ISN] Acceptable Risks"

    Forwarded From: phreak moi <hackereliteat_private>
    
    http://www.informationweek.com/698/98olkey.htm
    
    The Keys To Security
    
    Public Key Infrastructure is still evolving, but its security benefits for
    E-commerce and the enterprise are clear
    
    By Jason Levitt
    
    I'm counting the number of user-name and password combinations I need in
    order to use my desktop computer, and I'm not pleased with the results. In
    all, I have eight separate user-name/ password combinations that I need to
    install, and occasionally remember, for dial-up, E-mail, Web-site access,
    and groupware applications. In some cases, such as with POP3 E-mail, those
    user names and passwords are sent unencrypted over the Internet on a daily
    basis and are easy targets for villains with network sniffers and other
    types of nefarious tools. In the interconnected world of the Internet, as
    well as on the corporate intranet, it makes more sense to have a single
    secure, global "passport"-or "driver's license," if you will-for user
    authentication than multiple insecure user names and passwords. Digital
    certificates (sometimes called public-key certificates) are slowly
    becoming that driver's license for both corporate intranets and the public
    Internet. Used in conjunction with public-key cryptography techniques,
    digital certificates are used to securely identify people, servers, and
    other network-based entities. But though the digital-certificate standard,
    called X.509, has existed for some time, a management infrastructure for
    managing digital certificates, called Public Key Infrastructure, has been
    slow to evolve. A real driver's license can be obtained in nearly every
    city, has an expiration date, can be revoked, and is recognized across all
    state borders; a similar infrastructure must be in place in order to take
    full advantage of digital certificates over networks. 
    
    Currently, the Internet Engineering Task Force is driving the standards
    for PKI through its PKIX (Public Key Infrastructure for X.509) working
    group. Though the group was chartered in late 1995, draft standards for
    PKI details are only now reaching fruition.  Serious PKI deployments are
    not expected until sometime in 1999 at the earliest. 
    
    There are plenty of benefits to be reaped from putting PKI in place and
    widely deploying digital-certificate technology in applications.  For
    electronic commerce, the use of digital certificates allows a secure
    channel to be created between a client machine and an E-commerce server.
    Both parties can announce their identities by using certificates and can
    create an encrypted channel for communication. For financial applications,
    such as home banking and brokerage services, this kind of authenticated
    channel is a must. 
    
    In the corporate intranet, the obvious application is the single sign-on.
    Digital certificates for employees can be stored and retrieved using a
    Lightweight Directory Access Protocol-compliant directory server. The
    user's digital certificate provides authentication for all PKI-aware
    applications on the desktop. For remote access to the corporate LAN,
    digital-certificate technology can be used in conjunction with firewalls
    and virtual private network technology to grant employees secure access to
    the corporate LAN by tunneling over the public Internet. 
    
    Overall, with PKI implemented inside and outside the corporate intranet,
    total cost of ownership can be decreased by reducing theft due to security
    problems and by unifying the authentication mechanisms within the
    enterprise. 
    
    Key Cryptography
    
    It's almost a given that any data going across the public Internet can be
    intercepted by villains, without the knowledge of either the sender or the
    intended recipient. Nevertheless, sensitive E-commerce transactions pass
    over the Internet every day. How is that possible? Modern encryption
    methods for public and private keys render sensitive data unintelligible
    to eavesdroppers before it is sent over the wire. Although a villain might
    be able to intercept the data sent over the network, only the recipient
    with the proper "key"  can decrypt, read, and process the message. 
    
    Digital certificates, digital signatures, and secure communications such
    as those provided by Secure Sockets Layer make extensive use of both
    secret-key cryptography and public-key cryptography methods. In secret-key
    cryptography, the same key is used to encrypt and decrypt a message. It's
    called secret-key cryptography because the key should be kept secret.
    Anyone who knows the key has complete access to the message. 
    
    In public-key cryptography, two keys (known as a key pair)-a private key
    and a public key-are used. The public key is available to anyone and can
    be used only to encrypt messages. Similarly, the private key can be used
    only to decrypt messages created by encryption with the public key. If you
    want to send a secure message to me, you'd use my public key to encrypt
    the message. Since only I have the private key, only I can decrypt the
    message. 
    
    A digital certificate, sometimes referred to as a public-key certificate,
    is a piece of digital data that contains a public key, the name of the
    key's owner, and other information such as the expiration date and the
    algorithm used for encryption. All of that information is digitally signed
    (encrypted) using the private key of a certificate authority. The
    certificate authority is the entity that issued the digital certificate
    and can verify that the user does, indeed, own the public key contained
    within the certificate. And that's the point of a digital certificate-to
    prove that the public key contained in the digital certificate actually
    belongs to the key owner whose name is contained in the digital
    certificate. Once the certificate is verified, a secure communication
    channel can be set up using the public key to encrypt messages sent to the
    certificate owner. 
    
    In practice, public-key cryptography is slow, so it's often combined with
    secret-key cryptography. For example, an SSL connection, used extensively
    with Web browsers connecting to E-commerce systems, uses public-key
    cryptography to establish the connection-and then uses secret-key
    encryption to handle further data sent across the connection. 
    
    Critical Step
    
    In the online world, digital certificates are like a driver's license-they
    contain all the relevant information to prove your identity. But just like
    a driver's license, they can be forged. A certificate authority is like a
    state's driver's license bureau. It issues certificates to individuals,
    businesses, and other online entities so that these entities can identify
    themselves in online transactions. Because of the ease of forgery in the
    digital medium, though, certificate authorities perform one further
    critical step: They can verify that a certain digital certificate really
    belongs to that entity (just as a license bureau can verify the
    authenticity of a driver's license it issued). 
    
    In the physical world, we've learned to trust the driver's license
    bureaus. They form an infrastructure that stretches across the United
    States. In the online world, though, anyone with the right software can be
    a certificate authority. This can create problems because users need to
    trust the authority in order to trust the digital certificates it issues.
    In a business intranet, you simply trust your local certificate authority.
    On the Internet, the bulk of online certificate authentication is
    performed by VeriSign Inc., but over the next few years, many other
    organizations, such as the U.S. Postal Service, will also become
    certificate authorities. 
    
    Netscape and Microsoft have included certificates from
    "trusted"authorities in their Internet Explorer 4.0 and Communicator 4.0
    browsers. Although that's OK for Internet use in general, most companies
    would prefer to dictate which certificate authorities to trust. If one
    that's included in those browsers errs and issues a digital certificate to
    a rogue Web server, everyone running the shipping versions of those
    browsers will trust the certificate and create a secure connection with
    that server. Also, the browsers contain no logic to check for revoked
    certificates. In other words, if a server's certificate has been revoked,
    the browsers won't know that and will continue to trust it. 
    
    Keys To Management
    
    Public Key Infrastructure is all about managing keys and certificates over
    their lifetime-and that can be a very long time. Although keys may expire
    and become outmoded because of new and better cryptographic techniques, in
    many cases, businesses and users will still have legacy data encrypted
    using old keys. Thus, one necessary function of PKI is that it must back
    up and maintain records of certain old keys. 
    
    Of course, like any good driver's license bureau, PKI also issues digital
    certificates and maintains certificate revocation lists.  Because
    certificates can be revoked at any time, applications will need to check
    those lists frequently to ensure that a user's digital certificate is
    still valid. 
    
    In most companies, digital certificates are typically stored on an
    LDAP-capable directory server. Systems such as Entrust Technologies' PKI
    software can store digital certificates on many different LDAP-compliant
    directory servers, such as Netscape's Directory Server. 
    
    In many enterprise settings, single sign-on will be the first major
    application of PKI. To gain access to their desktops, users will log in
    with a user name and password that unlocks their secret key, which is
    stored on their local machine. Using their secret key, users can send out
    a digital certificate that validates their identity to the various
    applications. In order for single sign-on to work, however, applications
    have to understand the PKI protocols, which are defined in the various
    requests for comment created by the IETF's PKIX group. Also, directory
    servers, such as Novell Directory Services and Microsoft's Windows NT
    5.0's Active Directory, must be LDAP-compliant and have software that
    understands how to store and retrieve certificates in the directories.
    Unfortunately, because PKIX standards are just now maturing, PKI-aware
    applications are tough to find. Products such as Entrust's PKI software
    will be bundled with NetWare 5.0's NDS next year. 
    
    Effective Solution
    
    In the physical business world, we learn to trust things we can see,
    smell, and hear. If we are a retailer, we can see the cash and trust that
    it has a certain look and feel, and that it's sufficiently hard to forge.
    Further, we can demand a driver's license and signature for personal-check
    or credit-card transactions to authenticate purchasers' identity and
    legally bind them to a transaction. In the virtual world of the Internet,
    it's not so simple. 
    
    Digital certificates, combined with PKI, are currently the best bet to
    authenticate users and provide secure transactions over the Internet. The
    public cryptography methods are complex, but PKI will shield users from
    that complexity. 
    
    "The secret is to make it transparent to end users. End users don't want
    to hear about it, see it, or touch it," says Brian O'Higgins, chief
    technology officer of Entrust Technologies. "It's too complicated a
    beast." 
    
    -o-
    Subscribe: mail majordomoat_private with "subscribe isn".
    Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:03:41 PDT