WO2000014925A2 - Method and system for the protected distribution of network files - Google Patents

Method and system for the protected distribution of network files Download PDF

Info

Publication number
WO2000014925A2
WO2000014925A2 PCT/IL1999/000497 IL9900497W WO0014925A2 WO 2000014925 A2 WO2000014925 A2 WO 2000014925A2 IL 9900497 W IL9900497 W IL 9900497W WO 0014925 A2 WO0014925 A2 WO 0014925A2
Authority
WO
WIPO (PCT)
Prior art keywords
file
client
server
peer
response
Prior art date
Application number
PCT/IL1999/000497
Other languages
French (fr)
Other versions
WO2000014925A3 (en
Inventor
Yehuda Hahn
Original Assignee
Musicmarc Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Musicmarc Inc. filed Critical Musicmarc Inc.
Priority to AU58810/99A priority Critical patent/AU5881099A/en
Publication of WO2000014925A2 publication Critical patent/WO2000014925A2/en
Publication of WO2000014925A3 publication Critical patent/WO2000014925A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Definitions

  • This invention comprises a method and system for the protected distribution of network files.
  • CDs compact discs
  • CDs are mastered with a digital recording of music at 44,000 samples per second in stereo. Each CD holds a maximum of 660 megabytes of data, or 74 minutes of music. At current transmission rates (assuming a clean 56k connection of 7 kbps), it would take 26 hours for a user to retrieve a CD recording over the Internet.
  • a fixed transmission rate is combined with an unreliable transmission method.
  • Streaming sound sources are broadcast at a compression ratio that ensures that an approximation of the sound will be heard at the receiving end if the user receives all of the packets in their correct order (packets are discrete units of data transmitted over the wire).
  • packets are discrete units of data transmitted over the wire.
  • streaming does not guarantee that all packets will be received in order, a drawback that can cause transmission delays.
  • Streaming is primarily used by Internet radio stations, which do not expect the user to save a recording of the stream. Streamed sound is comparable in quality to an FM radio station under normal network conditions in a dialup 56k environment.
  • Image recording copies the image (file) of a track from a CD and compresses it for future use.
  • the compressed file is not intended to be streamed in real-time, and generally takes considerably longer to retrieve than the actual playback time.
  • MP3 is a merge of these two concepts.
  • An MP3 (MPEG-1, Layer 3) file is an image of a stream format, which is converted to a stream at relatively high bandwidth. MP3 conversions of 128 kbps can achieve CD-quality recordings, which can theoretically be streamed over a dual ISDN line, although some forms of music require the higher 192 kbps to achieve proper fidelity.
  • An MP3 file is compressed at a ratio of 12:1 to 14:1 for maximal output performance, although it can be compressed to up to 96: 1 if quality is not important. This is similar to the ratios of JPEG files for images, where image quality is degraded by high compression ratios.
  • MPEG audio coding shrinks the original sound data from a CD by a factor of 12, without losing sound quality. Factors of 24 and even more maintain a sound quality that is still significantly better than that received by simply reducing sampling rate and resolution. This is realized by perceptual coding techniques that imitate the perception of sound waves by the human ear. Using MPEG audio, one may achieve a typical data reduction of
  • MPEG Layer-3 is the most powerful member of the MPEG audio coding family. For a given sound quality level, it requires the lowest bit rate - or for a given bit rate, it achieves the highest sound quality.
  • MPEG Layer-3 proved its superior performance, maintaining the original sound quality at a data reduction of 1 :12 (around 64 kbit/s per audio channel). If applications tolerate a limited bandwidth of approximately 10 kHz, a reasonable sound quality for stereo signals can be achieved even at a reduction of 1 :24.
  • the ITU-R International Telecommunication Union - Radio Communication Sector
  • Ripping is the procedure used to convert a CD track into an MP3 file. Ripping itself is not illegal, and neither are the tools necessary to rip a CD; only the actual redistribution of the "ripped" file is illegal. Ripping for redistribution consists of three steps: l)Reading the CD track. 2)Encoding the CD track into MP3 format. 3)Uploading the MP3 file to a distribution server.
  • Reading Reading the track can be accomplished using any of a large number of utilities.
  • CDCopy can retrieve tracks from CDDB servers and lyrics from lyric servers (CDDB is a freeware server of CD and track titles that can be automatically matched to CDs. Lyrics servers allow matching a CD track title to its lyrics).
  • the system automatically outputs WAV files, which are uncompressed images of the sound on the disk and are typically 20-80 megabytes each. Track information in this illustration was retrieved automatically from a CDDB server and lyric information was retrieved from a lyric server. All of these programs and services are free to the online community (CDCopy is only free for a limited trial period).
  • Encoding the track can be done using the same program.
  • the file we ripped, Centerfold from J. Geils Band is about to be converted into MP3 format.
  • the options allow different degrees of compression and sound quality; the preset format converts the WAV file recorded from a CD to an equivalent quality MP3 format.
  • the original WAV file was 38.8 megabytes.
  • the compressed MP3 file is 3.5 megabytes.
  • the following illustration shows what the file looks like when played on a freely available MP3 player: WinAmp.
  • HTTP HyperText Transfer Protocol
  • FTP File Transfer Protocol
  • HTTP is the "language" of the World Wide Web. HTTP requires the use of a standard web browser, and is very user-friendly. To publish a file to an HTTP server, one needs an account on a matching FTP server or a publication system such as Microsoft FrontPage.
  • FTP File Transfer Protocol
  • FTP is an older protocol than HTTP, designed for the efficient transfer of files.
  • FTP requires a program known as an FTP client.
  • Web browsers can work with FTP servers, but due to the constraints of most illegal servers a web browser is not considered efficient and may be blocked by the server.
  • a remote server is the usual means of "trading" MP3 files.
  • the server operator will place a large initial collection of MP3 files on the server, to encourage traffic.
  • Retrieval (or downloading) of the files is generally subject to the "ratio" system, wherein a client who wishes to download an MP3 file from the server must first send (or upload) an MP3 file from his own collection, and may only download a certain number of files for each file uploaded.
  • SMB Server Message Block
  • CIFS Common Internet File System
  • ScourNet a popular MP3 portal
  • SMB index and publish files from users who do not wish to use the complexity of FTP or HTTP publishing. These files remain on the user's computer and can be downloaded using the ScourNet Scour Media Agent client.
  • SMB is an open standard and may be implemented by other search engines in the future; at the moment only ScourNet has done so.
  • Liquid Audio is partially owned by Intel. Partners include major names in the online music industry, including Music Boulevard and Billboard. The Liquid Audio Network claims to have 1500 artists.
  • Liquid Audio uses a multi-pronged approach including watermarking, encryption, and a special server format.
  • LA tracks must be mastered using a special encoder on the server, streamed using a special server, and then played using a proprietary player. Tracks are eO using Dolby Digital encoding (which can compress up to 176:1), and low-quality preview tracks are created automatically. Non-musical information can be added to the stream, including liner notes, lyrics, pictures, etc. The encoder sells for $295.
  • LA requires a Music Server as well, which includes full database connectivity, music services, online watermarking and adjustable streaming rate. Music Server reports royalties to copyright holders and tracks sales automatically, and is a full end-to-end solution.
  • the player a free application called Liquid Player, allows secure storage and mastering of CD-Rs based on the purchased content. Only one CD can be mastered from each song in a locally cached collection.
  • Liquid Audio controls the key information necessary to purchase music via the Music Passport. Furthermore, LA has an "Operations Center” which controls royalty reporting. Although not clearly stated in the website, it appears that LA receives a fee for each track sold. Furthermore, there are “merchant certificates” that need to be purchased (apparently from Liquid Audio) and the server will only work with valid certificates. The server price was not disclosed on the site and is not available from third-party dealers. Disadvantages of Liquid Audio
  • Liquid Audio requires a proprietary encoder.
  • Liquid Audio entails possible privacy infringements due to its central server that tracks undisclosed information. No clear privacy statement is available.
  • the integrated solution includes a commerce solution.
  • Liquid Audio allows integration of promotional video and liner notes.
  • Liquid Audio's compression format may be more efficient than MP3.
  • Operations Center An online center operated by Liquid Audio that tracks sales, royalties, and ownership of each track supported by Liquid Audio.
  • the Operations Center also reports royalty statements automatically and acts as a Certificate Authority.
  • Liquid Player A proprietary decoder for music that allows controlled playback of purchased tracks, which remain encoded and watermarked. Liquid Player also supports lyrics and promotional material.
  • Intertrust InterTrust describes its Business as providing "Software and services for selling intellectual property securely over the Internet.” Its software stores valuable files and governing rules in container-based, encrypted data files called DigiBoxes. Each person who downloads these files can pass it on to another, under the same rules about payment and copying. PC users need a special piece of InterTrust software, which is expected to be widely distributed for free.
  • InterTrust is not providing an end-to-end digital distribution system alone, it does want to be the center of a consortium of companies that will provide completely integrated digital-distribution systems for any kind of content, including digital music downloads.
  • InterTrust's business model proposes the licensing of a group of companies that will have the right to provide products, services and integrated solutions in a global e-commerce model called the "MetaTrust Utility". InterTrust will not compete with the MetaTrust participants, instead it envisions itself in the role of a utility (i.e., natural monopoly) that will serve in a "truly neutral capacity" to establish and maintain trust among content owners, distributors, service providers, clearinghouses, distributors, retailers, and consumers. Through its technology and leadership, InterTrust will assist in assuring ongoing interoperability, security and trust between the different MetaTrust licensees.
  • a utility i.e., natural monopoly
  • InterTrust is not one of the security providers supporting the continuance of traditional business models, in which record companies retained tight control over content and vendor partners. Instead, it has been an evangelist of "superdistribution” and “viral marketing,” i.e., consumers becoming participants in product marketing and fostering “pass along” sales.
  • InterTrust is a provider of generic systems for information security extending beyond the Enterprise to Extranets (Enterprise Edition 1.2), as well as commerce systems for digital information products (Commerce Edition 1.2). We will not discuss these in detail, but will mention another product, the MP3Plus Authoring Application Developer Kit. According to the InterTrust Web site, using the MP3Plus Kits one can: » Market, sell, and fulfill music — from singles to compilations — over the Internet, e-mail, DVDs, and CDs. • Integrate and persistently protect the artistic integrity of music, video still images, text, and graphics in a single multimedia Internet-ready product.
  • kits include both security and Digital Rights Management (DRM) functionality: a sample MetaTrust-certified MP3 player, sample music multimedia DigiBox® containers (the trusted InterTrust security technology) and business model templates, a Commerce ModelerTM, Layout Editor, Packager, and Rights WalletTM.
  • DRM Digital Rights Management
  • the purpose of this invention (hereinafter "MusicMarc”) is to prevent unauthorized reproduction of data during its transmission on a network, and unauthorized distribution of the data after it has been received. It is designed to provide maximum transparency of use to authorized users, while presenting maximum difficulty to those who attempt to use it illegally.
  • the problem of unauthorized reproduction during transmission is technically unrelated to the problem of unauthorized distribution. Both problems must be solved in order to provide the security required by the growing demands of electronic commerce. MusicMarc solves each problem separately, and incorporates the solutions into an integrated system capable of meeting these demands.
  • MusicMarc prevents unauthorized reproduction of a transmitted file by the following method: (a) chaffing selected packets of said first or second order series of packets;
  • “Surfer ID” is a method for authenticating two peers wherein the authentication protocol is reciprocal and based upon a shared secret key derived from a random seed on the peer's designated Server for that side of the algorithm. The method includes the following steps:
  • the invention further provides for a system for authenticating two peers within an authentication protocol, the peers are associated with a shared secret common to said peers and an identical randomization algorithm that utilizes a pseudorandom generator, the system comprising:
  • (c) transmitter transmitting the at least one packet and said response or derivative thereof to said challenging peer; (d) the challenging peer applying said algorithm as stipulated in steps (a) and (b) and compares the so-obtained response to that received from the challenged peer and in the case of match said challenged peer is authenticated.
  • the invention provides for a system for chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section, the system comprising:
  • the invention further provides for a system for de-chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section; selected portion ofsaid file being chaffed by at least one chaff key derived at least from said COA section or portion thereof, comprising
  • the First or Second Key includes or is derived using at least one item from the following list: receiver's name, receiver's credit card number, receiver's bank account number, receiver's address, a system signature, a bio-metric signature, a digital signature, or a common datum.
  • the Second Key includes information specific to the file-receiving side.
  • the first or second randomization algorithm is selected from the list: RSA, DES, Mersenne Twister, MD5 hash, a cipher algorithm, a one way hashing function, a shared secret dependent function, a two way encryption function, a pseudo-random number generation function.
  • Files contain content interpretable as music, text, graphics, video, hypertext, or multimedia. According to significant variation embodiments the file is compressed or encrypted.
  • MusicMarc aspects of an embodiment of the method of the present invention wherein music is the file content
  • the present invention relates to a system for the protected distribution of a file over a network, said network having a first and a second computer device interfaced via an inter-mediating communications network, and a file transfer protocol provided therein, wherein the computers of the system substantially execute the steps of the method as herein described.
  • the existing MP3 server is a WWW, FTP, or SMB server containing MP3 recordings of media artists, including all standard ones available today through the pirate channel.
  • the MP3 server does not need to be restructured except in location, where it will be behind the SurferlD Server and inaccessible to the Internet.
  • the SurferlD Server filters and authorizes relevant connections to the Media Server. It selectively allows FTP RETR retrievals, WWW GETs and SMB file copy operations based on the SurferlD authentication algorithm. Files designated as licensed are transferred through the SurferlD authentication channel only.
  • the Billing Server logs connections to the Media Server, and handles accounting vis-N-vis the copyright holder. Transactions between the Media Server and the client are not tracked by the Billing Server, but the Billing Server notes some characteristics of each transaction that takes place and assists in financial transactions. The Server may charge the client independently.
  • the Billing Server does not track the name or private information of the purchaser, and can be used in multi-level environments in which the client-server transaction does not take place at the retail level.
  • the SurferlD Media Client uses SurferlD and a standard web browser to retrieve files. Purchase is done securely through any independent means - SurferlD does not handle financial transactions directly. Files are retrieved through the SurferlD authentication protocol as payload stream packets (using an extension to the SurferlD protocol) and are watermarked using licensed watermarking technology. Files are also encoded with chaff on the client, limiting playback to the machine to which they were downloaded. 7.5 The MP3 Player: Marked MP3 files may be played by the client as often as desired and may technically be uploaded to pirate servers and redistributed. However, they will be marked with the watermark of the purchaser and may be scoured by Net search agents. Only a standard MP3 player is needed to play the MP3 files.
  • SurferlD is used to authenticate the connection between Client and Server.
  • SurferlD provides an open interface to all methods of Client authentication in a Server-independent manner.
  • SurferlD is a system-independent one-to-one authentication system utilizing shared secret authentication and a proprietary protocol based on open standards.
  • SurferlD offers a lightweight, portable Client that can be embedded into applications and devices.
  • SurferlD is positioned as the Internet equivalent of Caller ID in telephony applications, allowing full user identification in every connection to the Server.
  • SurferlD is based on the proprietary CHA protocol developed by Focus Communications Ltd. and licensed to MusicMarc Corp., which provides dynamic continuous authentication for remote-access capable devices and networks.
  • the existing SurferlD technology is used as a base for the authentication engine. The following extensions to SurferlD are required:
  • the authentication channel as a file transmission channel. 3. Watermarking
  • the Billing Server will maintain a separate SurferlD authentication session with the Media Server and will debit an account when the Server reports a successful download of an MP3 file.
  • the Client will also notify the Billing Server to prevent Servers from blocking notification.
  • the authentication channel as a file transmission channel.
  • Transferred files above a certain size will be transferred through the authentication channel to authenticated users and will not be transferred otherwise. Transferred files will be "chaffed” using MusicMarc chaffing technology (See the section on chaffing for details). In this case, SurferlD will filter content such that "anonymous" users can browse freely any part of the site, but will not be able to access media files, except as determined by the Billing Server. Unauthorized users will receive either a "demo" file from an alternative source (as defined by the Server or the Billing Server) or will be denied access entirely. The Billing Server will not receive information about which user purchased the file, only that the file was purchased. Watermarking
  • MusicMarc may use licensed technology from a watermark patent holder to watermark received files on the Client. Watermarking on the Client prevents sales information and Client usage information from reaching the Server unless the Client violates his license and redistributes the file.
  • Chaffing technology will prevent a watermarked file from being easily copied without the use of encryption.
  • a "chaffed” file will have a deliberately introduced carrier waveform that corresponds to the SurferlD of the user. The carrier waveform will be overlaid on the music waveform.
  • a file driver will seek the waveform in each output stream, and will remove it if it matches the SurferlD of the user.
  • “Chaffed” MP3 files can be played on hardware devices using a licensed chipset only.
  • the chipset will include suitable means of transfer and identification via the host computer or a SurferlD-supported Client verification driver.
  • Encryption is processor-intensive. MP3 decoding is a processor intensive activity by itself without adding a cryptographic engine. • Encryption does not provide accountability. A decrypted file can be freely reused and is not traceable. Watermarking is impossible to remove without damaging the underlying file, while the use of the authentication channel as a file transmission channel makes it difficult to reconstruct a valid MP3 stream from a "sniffed" session. While encryption can be added to the process, it would not contribute to security. It should be noted that in all cases a file can be intercepted at the device level while it is being played and reconstructed into an anonymous sound file unless watermarking is used. Encryption has a place in SurferlD Media Client in the following areas:
  • the Client itself uses encryption internally (when allowed by the country) to protect itself from reverse engineering. This encryption is limited exclusively to the user identification and the associated executable code, and licenses for this encryption may be easier to obtain than for the generic encryption of messages.
  • SurferlD will not provide the necessary infrastructure for SET or other financial transactions, as micropayments on the level of licensing a single track do not justify the overhead of a SET based system, and many alternative business models not involving financial transfers on the track level may be utilized using the technology.
  • a licensed Media Server receives a specific license for each file, which may have a value attached to it.
  • a reported sale allows the Billing Server to debit the account of the Media Server, and charge the Media Server at the end of a billing cycle.
  • Chaffing is the superimposition of a unique numerical value on a designated percentage of the frames composing a digital audio file, creating audible distortion on the file. Chaffing secures a file by allowing only one authorized device, that capable of generating the correct dechaffing key, to filter the chaff off a given file for play. Chaffing also protects the integrity of the COA; as a functional component of the dechaffing process, the COA cannot be tampered with.
  • the first packet to be transmitted is the COA.
  • the current System Key at the start of transmission is designated the Temporary File Key, and is stored in a temporary database within the Client.
  • the Final Song Key is used to chaff the full scrambled file.
  • the Temporary File Key is used to unscramble the file, which is still chaffed by the Final Song Key.
  • the Client assembles the key sources required to generate the final chaffing key. These sources include the Final Song Key, the COA checksum (see 1.3.5), the song's rights in binary flag format, and any other elements established by the Server prior to transmission. At this point, the file is protected with a unique chaffing pattern (with the exception of the designated clear header), which can only be filtered using the data stored in the host Client's CDB in conjunction with the Surfer ID.
  • the Chaff Database (CDB) resides within the MusicMarc Authorization Request Client on the host PC.
  • the CDB contains the data necessary to generate chaffing keys for all transformations of MusicMarc-enabled audio files authorized by the COA rules (that is, chaff transformations for a portable device or portable media).
  • the CDB contains a checksum derived from the COA of each file, which constitutes a primary source for the chaffing key. If the COA of a given file contains a different user's Surfer ID, or is tampered with, the CDB will generate a chaffing key that doesn't match the chaff on the file, and the user's audio player will run a chaffed file. Goals
  • the SurferlD Media Server architecture is targeted at the music industry, and provides a legal alternative to the current situation wherein recordings, implemented in MP3 files, are freely available from various servers without any accountability.
  • the SurferlD approach includes the following points:
  • Non-invasive Existing sites do not need to be modified to utilize the Media Server.
  • MP3 "catalogs" can be retrieved using the existing search engines and retrievals can be initiated in the standard manner. Only the actual transmission of MP3 files is done through the Client, which intercepts the file transfer request at the Server and Client levels.
  • the Media Client allows the user to continue to use his favorite MP3 player and allows offline playing of standard files.
  • Master file servers Store the original MP3 files. These servers are heavily secured and MP3 files cannot be retrieved directly from the servers.
  • 9.4 Accounting/Billing Server Tracks royalties and payments. For a user to retrieve a file, the Accounting Server must authorize the download. The Billing Server allows smaller servers to clear their royalty payments.
  • 9.5 SurferDD Client Utilizes a universal identification system. Different levels of security and identification are available as supplied by the
  • Each Client includes the watermarking module and a noise-cancellation system that allows playback of MP3 files locally.
  • Figure 1 illustrates MPEG Layer-3 Performance Data.
  • Figure 2 illustrates The CDCopy User Interface.
  • FIG. 3 illustrates The WinAmp User Interface.
  • Figure 4 illustrates The CuteFTP User Interface.
  • Figure 5 illustrates Search Results for the Pattern "Centerfold.”
  • Figure 6 illustrates Liquid Audio Architecture.
  • Figure 7 illustrates MusicMarc Architecture.
  • Figure 8 illustrates the Trust Relationship
  • FIG. 9 illustrates Music Marc Deployment Architecture.
  • Figure 10 illustrates Known Attacks.
  • Figure 11 illustrates SurferlD Components.
  • FIG. 12 illustrates VCD Structure
  • Figure 13 illustrates the Queue.
  • Figure 14 illustrates the MusicMarc Client Component Map.
  • Certificate is an implementation defined data block that is inserted immediately following the header.
  • the Certificate is composed of XML fields. Some of these fields are supplied by the Server and some are supplied by the Client.
  • Certificate of Authenticity is an ID3v2 standard tag type "XCA” or "XCOA” (depending on ID3v2 version) containing an XML file.
  • the XML file has fields that allow identification of the file and licensee of that file.
  • the COA is generated by the MusicMarc Client and appended to the beginning of the MusicMarc track.
  • a COA is based on the Certificate block and some data inserted by the Client.
  • Chaff Database is a hidden database that contains records allowing a chaff decoder in MusicMarc to identify the MusicMarc Track being decoded.
  • Challenge refers to the first half of a message.
  • a challenge contains a command for the peer processor.
  • Client ID (internally referred to as a VC Serial Number) is an arbitrary value that defines the Client to the Server and vice versa.
  • a Client ID cannot be used by itself to determine anything about the customer, but can be used as a database key if a customer database exists independently.
  • a Client ID is only valid if a CHA transaction occurs immediately after presentation of the ID and that transaction completes successfully. There is no mathematical relationship between shared secret values and the Client ID.
  • Client refers to the program executing on a customer (q.v.) computer that interfaces with either a SurferlD or a MusicMarc Server. Also referred to internally as Verification Client.
  • Cookies are persistent data blocks written to a Client or the computer upon which a Client resides for the purposes of tracking. They are used in SurferlD and MusicMarc to bind a specific web browser to a Client.
  • Customer refers to the human user of the Client program, who is licensed to use the program to access data that is otherwise guarded by SurferlD or MusicMarc.
  • Download Queue is one or more paid queues. Once a track is in a download queue it may be downloaded by the customer at any time. A track is removed from the download queue once the individual queue itself is deleted.
  • File Definition Record is the record that defines the file that is to be transferred, including its filename and attributes, as well as size.
  • the FDR also includes the header size, and the trailer size, and the total file size.
  • the FDR packet is also used to calculate the frame transfer order. The frame count and frame size is inferred from the packets transferred after the trailer packet. Each frame packet must be the same size.
  • Frame Group is a number of MP3 frames grouped into a single block that is chaffed as a unit.
  • Frame Transfer Order is the order that frames are transferred in. This order is set by RNG iterations from the FDR packet.
  • Frames are fixed portions of a file being transferred, sent out of order.
  • Guarding refers to the process of preventing a customer or other agent from obtaining his shared secret values, or any other protected data as appropriate. This process may include operating system hooks, anti-debugging code, obfuscation, encryption, and/or hardware protection.
  • the data/code to be guarded is only accessed/executed upon presentation of a proper System ID.
  • the Server is guarded by the SurferlD system.
  • a MusicMarc track is guarded by the System ID and an appropriate MusicMarc Client installation.
  • Header is the first part of the transferred file. It is sent following the FDR and copied verbatim to the beginning of the file buffer.
  • HTML or Hypertext Markup Language refers to the HTML 3.2 Standard definition or higher, without DHTML or scripting requirements.
  • HTTP(S) or Hypertext Transfer Protocol / Secure Hypertext Transfer Protocol are protocols defined as international standards. HTTPS refers specifically to HTTP 1.0 or higher using SSL 2.0 or higher.
  • IIS refers to Microsoft Internet Information Server version 2.0 or higher, used in the release version of SurferlD.
  • Internal Web Site or Private Web Site refers to the Web site that is guarded (q.v.) by SurferlD.
  • ISAPI Internet Server Application Programming Interface
  • ISAPI Internet Server Application Programming Interface
  • K value is a pointer number that is used in the Mersenne Twister tt800 or ttl9937 algorithm. SurferlD uses this number and it is thus stored in the shared secret.
  • Login refers to the presentation of credentials to a peer.
  • Message is a specific data structure passed in a stream that contains a challenge command, parameters, a response, and an optional payload.
  • a list of messages for each form of stream appears as part of the algorithm documentation.
  • a message may also be referred to as an XCHG.
  • a message that contains a payload is referred to internally as a XCHGEX.
  • MusicMarc Track is a track that includes a Certificate of Authenticity and is entered into a chaff database.
  • Peer refers to either the Client or the Server, in the context of the Server or Client respectively.
  • HTTP Ping refers to a single message transaction between peers.
  • HTTP Pings are message transactions that use a Web browser. Ping does not refer to the ICMP PING packet type.
  • POST Block refers to a HTTP response that was sent by the Client and corresponds to the HTTP POST command specifications.
  • Processor refers to a finite state machine or other similar virtual computing device that accepts fixed inputs and produces a fixed output based on the state of the machine and its inputs.
  • Public Site or External Site or Internal Public Site refers to the Web site that is not guarded (q.v.) by SurferlD and may exist within or outside of the SurferlD network domain.
  • Queue is a track in the progress of transmission.
  • a queue consists of the FDR, header, trailer, and reordered frames.
  • Random Number Generator refers to an implementation of the Mersenne Twister algorithm or an iteration thereof. All random number generators used in MusicMarc and SurferlD are Mersenne Twister derivatives.
  • Response refers to the second half of a message. A response contains the calculated value the was output from the local processor based on the previously received challenge.
  • Server ED is an arbitrary value that identifies the Server. It serves the same function as the Client ID.
  • Server refers to a program that supplies services to a client over a network connection.
  • Service Control Manager refers to the Windows NT Service Control Manager, which is defined in the Windows NT API documentation.
  • Shared Secret is a collection of values that uniquely identifies a user and is found on both the Client and Server. It is guarded by the System ID and consists of the chaff database (in MusicMarc implementations) and the x and k values for the SurferlD authentication system.
  • Stream or socket refers to a network connection, either a TCP/IP network connection or a named pipe.
  • a persistent stream is backed by mass storage in the form of a file or memory mapped file.
  • System ID is a general term referring to a unique value that substantially fits the following criteria:
  • a System ID can be a password, a set of computer metrics, a smart card, a biometric reading, or a network ID, or any combination of the above. Both SurferlD and MusicMarc require a 16-byte checksum with no character set restrictions.
  • Track refers to a bit stream in MPEG-1 Layer 3 format, recorded into a file.
  • Trailer is the end of the transferred file. It is sent right after the header. It is written following a reserved space for the frames.
  • Vci refers to the non-portable components of the SurferlD Client.
  • a VCI module is responsible for interfacing with the operating system, network and file system as well as all security aspects.
  • Vcp refers to the portable component of the SurferlD Client.
  • the VCP is a shared implementation and handles the actual algorithm of SurferlD.
  • X values are an array of numbers that is used in the RNGs on both Client and Server to create unique random sequences that identify the peers to each other.
  • a "Protocol” for allowing intercommunications on a network may be selected from the list:
  • RTP Payload Format for H.263 Video ST
  • MHTML MIME E-mail Encapsulation
  • HMAC-MD5 HMAC-MD5 IP Auth. with Replay Prevention
  • IMAPV4 Internet Message Access Protocol v4revl
  • NNTP Network News Transfer Protocol
  • RTP-MPEG Payload Format for Bundled MPEG
  • SD7T/UFT Sender-Initiated Unsolicited File Transfer
  • IMAP2 Interactive Mail Access Protocol
  • DMF-MAIL Digest Message Format for Mail
  • ERTP Internet Reliable Transaction Protocol
  • NVP-II Network Voice Protocol (ISI-memo)
  • PKCS-7 PKCS #7 Cryptographic Message Syntax Version 1.5
  • PKCS-10 PKCS #10 Certification Request Syntax Version 1.5
  • PKCS-1 PKCS #1 RSA Encryption Version 1.5
  • SMIME-CERT S/MIME Version 2 Certificate Handling
  • SMIME-MSG S/MIME Version 2 Message Specification
  • RC2-ENCRP A Description of the RC2(r) Encryption Algorithm
  • CAST-128 CAST- 128 Encryption Algorithm
  • RC5 RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
  • GZIP GZIP File Format Specification Version 4.3
  • ZLD3 ZLIB Compressed Data Format Specification
  • ADSNA-IP Advanced SNA/IP: A Simple SNA Transport Protocol
  • PCMAIL Pcmail Transport Protocol
  • IMAP3 Interactive Mail Access Protocol Version 3
  • RATP Reliable Asynchronous Transfer Protocol
  • RTELNET Remote Telnet Service
  • Mersenne Twister is a family of algorithms developed by Makoto Matsumoto and Takuji Nashumura of Keio University, Japan. For details on these algorithms please see the Marsenne Twister site at http://www.math.keio.ac.ip/matumoto/emt.html.
  • SurferlD utilizes the tt800 algorithm.
  • MusicMarc uses the WFC implementation of the Cokus variation of the ttl9937 algorithm. The exact implementation used is CRandomNumberGenerator2(a), and was implemented by Shawn Cokus, Sam Blackburn, and Yehuda Hahn. The code for the precursor version and associated notes is published by the WFC site at http://ourworld.compuserve.com/homepages/Sam_Blackburn/wfc.htm. Mersenne Twister algorithms and any implementation thereof are all public domain.
  • One Time Pads are commonly used in cryptography. A definition of one time pads exists at http://www.onetimepad.com/otpexplain.html. The One Time Pad algorithm itself is public domain.
  • XML is a tagged free-form database file format based on SGML. It follows an international standard. For definitions of XML see http://www.w3.org/XML/.
  • MD5 is a message-digest algorithm developed by R. Rivest in 1992. Full details are defined in RFC 1321.
  • TCP D is a defined protocol and a series of international standards.
  • the TCP/IP implementation used in the release version of SurferlD utilizes the Dundas Ultimate TCP/IP Class Library (referred to herein as "Dundas") over the Windows Socket standard library for Microsoft Windows 95/NT/CE.
  • SurferlD peer authentication relies on two identical processors with unique System ID and x values.
  • One processor executes on the Server, the other on the Client.
  • the two processors exchange messages on a periodic basis and each message may change the shared secret in either a persistent or non-persistent manner.
  • the persistent state of each processor can be fully defined in the shared secret at any time.
  • the non-persistent state is discarded upon receipt of a Clear command or upon initialization. Synchronization is upon message receipt; a processor may not assume receipt of a persistent message until the network confirms such receipt.
  • TT800 uses an array of 100 bytes (known as an x table) and a control value k (4 bytes) to determine which number should be generated next.
  • the array is modified as a result of this generation and the output [result and output are used interchangeably in this description] is used to calculate the next number.
  • the cycle of numbers is such that a stream of values, assuming a constant source array, is repeated only once every 2 times.
  • TT19937 uses an array of 624 DWORDS (known as an x table) and a control value k (4 bytes) to determine which number should be generated next. This forms a state value of 2500 bytes.
  • the array is modified as a result of this generation and the output is used to calculate the next number.
  • the cycle of numbers is such that a stream of values, assuming a constant
  • 19937 source array is repeated only once every 2 -1 times.
  • the TT800 algorithm is used as the core pseudo-random number generator in the CHA version 1 protocol.
  • MusicMarc uses TT19937 internally.
  • the number sizeof(x) will refer to 100 in SurferlD implementations and 2500 in MusicMarc implementations.
  • the term "RNG” will refer to TT800 in SurferlD and TT19937 in MusicMarc.
  • the Saved table is the persistent data that is modified when so requested by the Server.
  • the Workspace table is the data that is modified each time by the challenges (The data checksummed for the response is based on this table).
  • the Server does not send any message.
  • the Client initiates the handshake by supplying a 32-byte value identifying the Client.
  • the value is: # 416 bytes: Server ID
  • the Client ID is a unique 16-byte value assigned by the Server. In the case of a Client that supports multiple users, the Client ID must be registered for each user and must be unique to each.
  • the Server responds by sending a challenge. After the Client responds to the challenge, the user is authenticated.
  • the Client issues a challenge concurrently and may only answer to further challenges if the Server responds correctly to the challenge issued by the Client.
  • a challenge is a request that the Client take the existing array and manipulate it according to the instructions in the challenge.
  • the response primarily consists of the output of the transformation [in this non-limiting example being a MD5 checksum] calculated from the challenge. [In the rest of this description, the term checksum or hashing may be used as an example of transformation.] Additional fields in the response packet are:
  • IP address The IP address of the Verification Client.
  • VC Serial The serial number of the Verification Client
  • the VC Serial and Local signature fields are not used in the CHA response, but are only initialized for the HTTP response.
  • each challenge has a response in it as well.
  • the initial Server packet has only a challenge, with the response field left blank.
  • the response format of a HTTP response is the same as a regular CHA response.
  • the response is converted to text before it is sent.
  • the algorithm is a very simple one designed to quickly convert values into a safe text value, bearing in mind that a packet 116 bytes long travels at exactly the same speed as one that is only 72 bytes long.
  • the algorithm converts each byte into a 16-bit value using the following bit transformation:
  • z;
  • Both y and z now have a bit pattern of ObOlOxxxxO.
  • the resulting 16-bit value is made by shifting y left eight bits and adding z.
  • the resulting bytes are always valid for an HTTP POST block.
  • the block is preceded by a three-byte identifier value.
  • the three-byte identifier is currently set to the letters ACK, which are all invalid values for the data itself (all three characters have a LSB of 1.) Note: all calculations assume a little-endian processor. In a big-endian representation changes may be made as needed.
  • Bytes are verified at destination by doing a simple bit check for AND Oxal and XOR 0x40. If either check fails, the packet is invalidated.
  • the packet is sent using the host browser and HTTP(S), by sending a POST request to a specific location, which is implementation dependent.
  • the location may include a GET request as well (e.g. http://surferid.somewhere.com/surferiaVvs_http_target7identifVmgmformati on&more identifyinginformation) as long as the actual request is a POST request and the identifying data is sent in POST.
  • the SurferlD ISAPI filter will re-map the request to the Verification Server ISAPI Extension (which is a separate entity from the SurferlD Server.)
  • the intercepting driver must pass the resulting value according to the rules of that protocol. For example, if the protocol is FTP, the driver may utilize a transaction method using PORT,
  • the ISAPI extension sends the response to the SurferlD Server, which validates the response and returns a cookie to the Client.
  • the cookie is unique in each iteration but is not a function of the response.
  • the Cookie holds the Client's IP address such as to identify the Client for all future requests until the next CX_HTTP packet is processed.
  • the cookie is valid only until the next cookie is issued. However, the expiration date of the cookie is set to a predetermined time after the next cookie is to be issued, to allow for network delays or OLE errors.
  • Both Netscape Navigator and Internet Explorer require that a browser window be open in order to process OLE commands. In the case of Internet Explorer it must be the same browser window as the one receiving the cookies, while in Netscape all browser windows share a common OLE Server.
  • the cookie tracking approach has one weakness that can be exploited, where the hacker's computer and the user's computer are on a common subnet behind a firewall, and both are perceived by the Verification System as coming from the same HTTP IP address (that of the firewall), and the hacker is intercepting packets sent to and from the Verification Client computer.
  • the attack also assumes that either the SurferlD system is not configured to use SSL or that the SSL security has been compromised in some way.
  • the Server consists of six major components. 1.Verification Server core 2. CHA portable implementation 3.0ut-of-band channel service 4.HTTP Proxy
  • Verification Server core The core consists of non-portable NT code that "glues" the components together and provides a security framework and implementation.
  • the core consists of the Gateway and Proxy Servers from the SIBLING system, merged into one service. Messages between the Gateway and Proxy have been removed. The only interfaces supported to the outside world are GefPage and FwPingResponse.
  • CHA and Encryption The CHA protocol implementation is portable and requires the core for implementation specific segments. Encryption uses the Finnish copy of the free Crypto++ library (The original Crypto++ library resides on a Canadian server and is not used to avoid legal issues). See the Crypto++ home page for details. (Note that encryption is only used in countries that allow it and only to the extent permitted by the exporting and hosting countries. Encrypted data is never transmitted except in initial setup of a Client. Encryption is entirely optional.) 11.3 OOB Channel Service: The OOB channel service is the module that transfers data from the TCP/IP network to the SurferlD Core Server. 11.4 HTTP Proxy: The HTTP Proxy consists of an interface between the IIS server and the SurferlD Core Server.
  • the HTTP Proxy server is part of the core. Additional proxies for other protocols can be added, but no formal add-in system is proposed for version 1.0.
  • 11.5 SAM Integration The SAM user database is used to authenticate users. The service account is used to access per-user data in the secret database, and authentication information is passed as HTTP authentication headers to the host web server. The SAM database is used to initialize user accounts and to verify passwords.
  • 11.6 Secret database The secret database holds Client and Server x/k combinations for the Client and Server state machines on a per-user basis. CHA uses this information to generate appropriate challenge/response pair messages.
  • Verification Client Setup System Consists of three modules: 1) The Verification Client Generator, which runs on the Server and is responsible for creation and distribution of the Verification Client, 2) 11.8 Verification Client Setup Control Program, which copies support files on the client side prior to execution of the actual Setup executable, and 3) The Verification Client Creator, which creates the Verification Client shared secrets file and actually performs installation.
  • the SurferlD Server performs three main categories of functions:
  • Verification Server Verifies Client ping responses against the database.
  • Connection to the Client is over a dedicated port. If the HTTP integration option is enabled, the Verification Client will also send responses over the HTTP channel. These will be directed to the SurferlD Server via an ISAPI extension.
  • Proxy Server Proxies HTTP requests from a local copy of IIS to the internal web site. Connection to IIS is over a secured named pipe.
  • Administration Server Handles administration of on-line users. Connection to the administrative interface is through a local socket.
  • the Surferlsapi Filter intercepts all HTTP requests and redirects them to the
  • HTTP Login extension .DLL is available to allow the user to enter his name and password in an HTML form. This option can be enabled per user. There are three login options: automatic, manual and administrator.
  • the Verification Client sends its login information to the SurferlD Server. If verified, the Client and Server will continue to exchange challenges and responses using the proprietary CHA challenge response system.
  • the Client responds to Server challenges and the Server responds to Client challenges.
  • the Client will be in an authenticated state either until he performs a logout or there is a mismatched challenge/response. In the case of a mismatched Server response, the Client will log himself out. While a user is in an authenticated state, all requests he makes of the web server will be redirected to the internal private site. When an unauthenticated Client makes a request, he will be redirected to the internal public site.
  • the filter checks each incoming HTTP request (IP Address and COOKIE) with the SurferlD Server to see if it is originating from an authenticated user.
  • the SurferlD Server sends all authenticated requests on to the internal private site along with the username and password as HTTP Authentication headers. All unauthenticated requests are send to the internal public site. The response is sent down to the filter, which passes it on to the Client's browser.
  • SurferlD Server is a multithreaded application. When the service starts up, it waits to receive notification that all required threads are running, and then reports to the Service Control Manager as started. The threads are all started by the Init function of Proxylnterface, and Init waits on the handle of MainPipeThread before proceeding to shut down.
  • the following threads run in the context of the service: • MainPipeThread: This is the main means of communication between the surferisapi filter and the SurferlD Server. It defines a limited message protocol, which only allows the filter to call certain functions.
  • Proxylnterface constructor defined by prxint.cpp
  • Prxint.cpp Proxylnterface constructor
  • Prxint.cpp Proxylnterface functions defined in that file.
  • AdminPipeControlIer This thread uses the Dundas server class. It waits for connections from the administrative interface, shuts down when the server event is set upon the MainPipeThread' s shutdown.
  • the administrative interface also has a limited message protocol, which can be sent over a local socket connection on a dedicated port.
  • CAdminThread OnConnect: The CAdminThread class is derived from the Dundas server class. It receives messages from the administrative interface, calls the corresponding Proxylnterface function, and sends the result back to the administrator. Only one connection is allowed at a time.
  • AnonPipeReader This thread receives a page request from the filter, and returns the response from the actual site to the filter. Multiple instances of the thread run, and upon starting each thread checks that there is always one available thread and if not starts one, as long as the total number of threads does not exceed the maximum number of connections as defined in the registry (See section on registry settings).
  • TimeoutThread This thread cycles through all current user sessions and sets to US_VCTIMEOUT those Clients who have not sent a response within the timeout (which is defined per Client).
  • This thread is the main verification server thread. It is also uses the Dundas server class and it waits for connections from Verification Clients, each of which starts up its own instance of an "OnConnect" thread.
  • SurferlD Server starts up an instance of this thread for it, which communicates between Verification Client and Server. It calls the Proxylnterface ::VCLogin and Proxylnterface: :SendPingResponse with the data it reads from the Client, and it sends the results of these functions back to the Client.
  • VCHTTPPipeController This is the controlling function for the HTTP Ping infrastructure.
  • SurferlD Server introduces the concept of HTTP Pings as an additional way to authenticate Clients. For Clients running from behind a proxy server, these pings are the only way to identify them. Verification Clients are identified by the IP address from which their pings originate. When they later make an HTTP request of the SurferlD Server, their IP address is checked against the list of running Verification Clients.
  • the IP address attached to the HTTP request is that of the proxy server and cannot be linked to that of the Verification Client through an ordinary check.
  • the HTTP Ping technology handles this problem.
  • the Server occasionally sends an HTTP Challenge. This requires the Client to send its response via a POST request to the verification ISAPI extension .DLL.
  • the verification .DLL in broad terms, simply reads in the response as a text string, sends it to the SurferlD Server via a named pipe, and receives a cookie in response, which it sets into the Client browser. This cookie is used by the surferisapi filter in all future HTTP requests from that Client in order to identify it.
  • the VCHTTPPipeController makes sure there is at least one VCHTTPPipeThread available to connect to the verification .DLL. First it starts the VCHttpPipeStarter thread, which waits on an event and creates a new pipe thread each time the event is signaled. Then it loops and checks the number of pipe threads to make sure it is not 0 or negative, due to unexpected thread failures. If it finds no running pipe threads, it creates one. Each VCHTTPPipeThread, upon starting, checks to see if it is the last available pipe and, if so, will set the event for VCHttpPipeStarter to begin a new thread.
  • the pipe thread Upon finishing verifying the HTTP challenge/response, the pipe thread checks to see if there is an available thread. If there is, it will exit. If there is not, it will continue to loop and wait for a connection from another instance of the verification .DLL.
  • VCHTTPPipeStarter This thread is started by VCHTTPPipeController. It waits on the MakeVCPipe event, and creates a new VCHTTPPipeThread each time the event is set.
  • VCHTTPPipeThread This thread waits for a connection from the verification .DLL and upon reading the response to an Http challenge, it verifies it and returns a cookie to the .DLL. Before connecting, the thread checks if there is another available thread. If not, it sets the MakeVCPipeEvent that the VCHttpPipeStarter is waiting on. At the end of this process, it checks to see how many available VCHTTPPipeThreads there are. If it is the only available one, it loops back to wait for another connection; if not, it exits.
  • LoginPipeThread This thread opens a pipe and waits for connections from the login extension .DLL, which is called for Verification Clients who are required to fill out an HTTP login form (where logintype is not set to LOGIN_AUTOMATIC). It receives the post block from the login form, and calls Proxylnterface ::HttpLogin to process it. It returns a pass or fail response to the extension, which will then set the user's state in the filter to US_RETRY_PWD or US_rNVALIDATED_LOGIN accordingly.
  • SurferlD is installed as a service in the local services database. All registry settings are under the parameters key in
  • HKEY_LOCAL_MACHrNE SYSTEM ⁇ CurrentControlSet ⁇ Services ⁇ SurferI D. They should only be set and changed through the administrative interface. Both the SurferlD Server and the Surferisapi Filter use settings in the registry read at startup; therefore, changes to parameters won't affect the Server until it is restarted.
  • AuthEnabled (REG_DWORD): Tells whether the internal private site is equipped to handle authentication headers or not. 0 disables sending of authentication headers, 1 enables it.
  • Loginpost The Http Login extension .DLL to which the loginpage POSTs.
  • Vctimeout the error page that the user receives if he is not allowed into the private site because of a timeout error.
  • the Verification Client generator key contains values described fully in the Verification Client documentation.
  • VIRTPD7E Encapsulates the overlapped part of overlapped i o calls on pipes. It contains a pipe handle and a pointer to the overlapped structure, so that reads and writes on pipes will internally perform the overlapped functions.
  • VSCOOKIE This structure is just a text string the length of the cookie set by the verification .DLL.
  • LOGINTYPE This is an enumerated type with three possible values: LOGIN_AUTOMATIC, LOGIN_MANUAL, or LOGIN_ADMINISTRATOR. See above documentation for explanation of these choices.
  • VCData The structure that stores all information relevant to the user's Verification Client.
  • vcview3 Class derived from CRecordSet which is used during VCLogin to get user information from the database looked up by his VC Serial.
  • CRSPARAMS Stores all information relevant to the Verification Client's challenges and responses.
  • CRSRESPONSE The structure that holds the response to a challenge.
  • CRSXMITHDR The structure that holds a challenge.
  • XCHG A structure made up of a CRSRESPONSE and a CRSXMITHDR that is "exchanged" between Client and Server. Each one verifies the contents of the response, responds to the challenge, and sends a new challenge back in the structure.
  • CRSHTTPRESPONSE The structure that holds the response to an HTTP challenge. Because this response doesn't affect bandwidth as much as the ordinary, more frequent responses, it contains a few more user details.
  • CRSCOOKIE The binary version of VSCOOKTE that is set into the user's page after the user posts an Http Response to the Server. A valid cookie will uniquely identify the user as an authenticated user.
  • the cha challenge response technology is a complex protocol for creating challenges, processing responses to challenges, and verifying those responses.
  • the challenge/response seed numbers are dynamic and the changes are persistent from login to login.
  • the three main functions are:
  • ProcessChaRequest Creates a response to a challenge.
  • ChaPersist Saves the Client's dynamic information so that it will persist to the next login.
  • Both the Client and the Server have structures, CRSPARAMS, which contain the dynamic random numbers and the capabilities of the Client (i.e. is it capable of sending HTTP responses? If not, no HTTP challenges will be sent.) These structures are initialized at VCLogin with the information taken out of the database.
  • the CRSPARAMS structures for the Client and Server are stored in the VCData member of the Client's SessionID structure.
  • the Client and Server each maintain a variable which holds the last challenge they sent out, so that they can verify the response that is returned to them.
  • the CRSPARAMS structure contains three buffers, which store the random numbers used to generate responses:
  • Chahttp Acts on the Client's side as a scratch buffer to generate HTTP responses, which do not change the chawks buffer, but do use the values currently in the chawks buffer.
  • chahttp holds the values that were present in chawks at the time it sent out the HTTP challenge, so that it can verify the response against those values when it receives the response, which could be much later.
  • Chawks and chahttp have corresponding "k" values.
  • ⁇ CX_CLEAR Means that before generating the response, the Client should set the values in his chawks buffer to those in his chabuf buffer, and reset his wksk to 0.
  • CX_GENRAND and CX_SKIP Are used internally in the CHA algorithm to control the iterations of the RNG loop.
  • CX_PERSIST Means that the values in chawks after processing this response should be saved back to chabuf and then to the database (or VCD file on the Client's end) so that the changes will persist to the next login.
  • ⁇ CXJHTTP Means that the response to this challenge should be sent via a post to verification .DLL, in addition to being sent through the ordinary channel. • Size
  • the response to the challenge is a md5 checksum of the buffer, which should be the same on the Client and Server's end.
  • the following flags can be set in the deRetFlags member of the CRSRESPONSE: .
  • VCR_HTTPRESP This response is being sent through a POST to verification .DLL and it should be verified against the values stored in the chahttp buffer. • VCRJE ⁇ TTPREQ: The next challenge sent out should be an HTTP challenge. This flag is set by the Server after it has received and finished processing the response to the last HTTP challenge and the lag time between HTTP challenges has already elapsed.
  • VCR_PASSTHROUGH When the Server receives a response to an HTTP challenge through the ordinary channel, that response should not change the chawks buffer or the corresponding "k" value, because on the Client's end, all processing of HTTP challenges is in a temporary buffer. It should not change the values in the chahttp buffer either, because those must be saved until a response is received through the HTTP channel. Therefore, when the Server receives a response with the VCR_HTTPRESP flag set through the ordinary channel, it sets that flag to FALSE and instead sets the VCR_PASSTHROUGH flag so that the processing of this response should not affect any of the actual buffers.
  • the Server When the Client first connects to the Server it sends its unique VCSerial number.
  • the Server then uses the GetClientAddress function, fills in a VCData structure with VCSerial and IP address, and calls Proxylnterface:: VCLogin. It returns the response to the Client, which disconnects if the response indicates a failure.
  • the Client then sends in a DWORD, which contains the flags representing its capabilities.
  • the Server calls Proxylnterface: :SendPingResponse with the XCHG structure containing an empty challenge, and the response containing only a deRetFlags member which uses the flags VCR_NOHTTP, VCRJUA E and VCR_UA_NETSCAPE to let the Server know its capabilities.
  • the Server converts those flags to the corresponding VCC_* flags and sets them in the Client's CRSPARAMS structure.
  • SendPingResponse' s next step is to check whether the Client is ready to receive an HTTP challenge. It checks whether the Client is capable of HTTP responses, then whether the response to the last HTTP challenge was received (which is notified by setting the VSHTTPready flag inside the Client's SessionID structure to TRUE), and last, whether the time lag between HTTP pings has elapsed. If all these are true, it sets the flag in the response structure to VCR_HTTPREQ.
  • the Server calls CreateChaRequest, passing it a pointer to a CRSXMITHDR variable to hold the new challenge created, a CRSPARAMS reference which contains the Client's dynamic seed numbers and its capabilities, a CRSRESPONSE reference which contains its response to the last challenge to verify, and a pointer to a CRSXMITHDR which contains the last challenge to verify.
  • CreateChaRequest the Server first checks if the last challenge is NULL. If there was a last challenge to verify, it then checks whether it is an HTTP response, or a response through the ordinary channel.
  • ProcessChaRequest With the last challenge, the fresh response variable, and the Client's CRSPARAMS.
  • This function is used by the Client to generate the response, so if the dynamic information inside CRSPARAMS matches on the Client and Server side (as it should with a valid Client during a valid session), ProcessChaRequest should return a response identical to the one sent in by the Client. After ProcessChaRequest returns, the generated response is compared to the response sent in by the Client. If they don't match, CreateChaRequest returns zero, for failure. If they do match, CreateChaRequest generates a new challenge for the Client.
  • VCR_HTTPREQ If VCR_HTTPREQ is set in the response, CX_HTTP will be set to TRUE in the new challenge. If the last Client challenge had CX_PERSIST set, the next one will have CX_PERSIST set to FALSE (See next section on persistent challenges). If it is an HTTP challenge, CreateChaRequest will store the current state of chawks and wksk in the chahttp buffer and httpk, and it will save this challenge in the httplast variable. Then CreateChaRequest returns.
  • the Server checks the result of CreateChaRequest, and returns 0 if it failed. Then SendPingResponse checks if the Client sent it a challenge in the XCHG structure. If so, it calls ProcessChaRequest to generate the response to that challenge. It then copies the new challenge it created in CreateChaRequest into the challenge part of the XCHG structure, and its own response to the Client's challenge into the response part of the XCHG structure. The Server checks the last challenge that it just verified to see if CX_PERSIST was set to TRUE. If TRUE, that means the Client saved its dynamic information after sending its response to the Server to be verified.
  • CX_PERSIST was set to TRUE, after a successful call to CreateChaRequest, the Server will call ChaPersist to save the Client's dynamic information to the database. After persisting, the Server overwrites the "last" variable, which holds the last challenge sent out in order to verify it. (If the response was sent through the HTTP channel, it does not actually send the Client the challenge created during the call to CreateChaRequest. That call is just to verify the response.
  • SendPingResponse returns to CVSThread::OnConnect (or FwHttpPingResponse in the case of an HTTP response) with its result.
  • the Server sends out the XCHG packet with the new challenge and the response to the Client challenge. If the send function returns successfully, the Server will then check if the last challenge it responded to had CX_PERSIST set to TRUE, and if so it will call CommitChaBuffers, which calls ChaPersist to persist the Server's dynamic information to the database.
  • the Server sits in a loop reading an XCHG packet from the Client, calling SendPingResponse, sending out a new XCHG packet, persisting Server information if necessary, and then returning to the beginning of the loop. If at any point a socket call fails (other than a timeout error) or the SendPingResponse fails, the Server performs a VCLogout and the thread exits.
  • the ChaPersist function is always called after the response was generated and the send of the XCHG packet to the other side was successful. On the side that verifies the challenge, ChaPersist is called after the challenge is verified. This is done to ensure that the dynamic information that is persisted is synchronized on both sides and is the same.
  • the Client is a self-installing transparent plug-in that authenticates access to a SurferlD Server.
  • the Client setup has the following design goals: • Each Client is unique.
  • a customer authenticates himself to the setup application using a password combination received from the Server.
  • the passwords are used to decrypt the setup package (where allowed); it is assumed that the Server administration will only give the passwords if the customer identifies himself adequately.
  • the setup application itself is generally sent either through e-mail, HTTP direct download, or media distribution.
  • the setup system automatically integrates the Client with web browsers.
  • the Setup application consists of three programs:
  • Verification Client Generator This module runs on the Server and is responsible for creation and distribution of the Verification Client.
  • Verification Client Setup Control Program This module copies support files on the client side prior to execution of the actual Setup executable.
  • Verification Client Creator This module creates the Verification Client shared secrets file and actually performs installation.
  • the SurferlD Verification Client Generator project consists of the following sections and modules: 1. Initial Passwords 2.VC Serial 3. Utilities
  • the Initial Passwords module interfaces with an ODBC data source. It consists of a standard derivation of CRecordset and exposes the following interface methods and variables: class InitialPasswords : public CRecordset
  • This interface is used in the workflow to determine the initial encryption key for the Verification Client.
  • PKID and user ID are used to query the interface.
  • the user ID and the PKID are determined by the input to the main entry point.
  • the DSN used to log in is defined as "SurferlD.” Access must be anonymous or encapsulated in the DSN open string and hard-coded into the class definition. Furthermore, the DSN must be a system DSN, as it is accessed by services as well.
  • the VC Serial module interfaces with an ODBC data source. It consists of a standard derivation of CRecordset and exposes the following interface methods and variables: class C VCSerial : public CRecordset
  • This interface is used in the workflow to update the serial number and x variables for the Server and Client on the newly generated Verification Client.
  • the VC Serial database is updated by the generator. If no entry exists for the PKID and user ID specified, a new record is added. The timeout is not updated by the generator and must be maintained by a separate tool on the server.
  • the DSN used to log in is defined as "SurferlD.” Access must be anonymous or hard-coded into the class.
  • the user ID and the PKID are determined by the input to the main entry point.
  • Utility Library contains all of the miscellaneous functions used by the generator. These functions may be reused in other contexts as well.
  • GenVCText creates a new VC serial number, of the format VCaaaabbbbcccdddd, where a, b, c, and d are 32-bit integers, rendered in hex.
  • StringToAddress converts a string IP address (dotted form) into a compressed DWORD in local byte order.
  • the return value is used in internal messaging but cannot be passed to socket functions that require network byte order.
  • the winsock byte ordering functions can be used to convert this IP address into network byte order if desired.
  • LPCSTR A string representation of the IP address.
  • (BYTE *) tribyte The three-byte representation (real).
  • (BYTE *) fa The four-byte representation (displayed).
  • the output buffer must be four bytes long.
  • Otuv wxyz OABC DEFG OHIJ KLMN OOPQ RSTU 0 is literal. Parameters:
  • the initial key is drawn from the Initial Passwords module.
  • the keys (initialPasswordl and initialPassword2) are run through the shavetop algorithm.
  • the resulting binary string forms the return value.
  • the return value is dynamically allocated using malloc() and must be freeQd.
  • Create VerificationClient does the following: 1. Generates user keys (using GenerateUserKeys).
  • the Create VerificationClient module has one function:
  • HWND Window handle to receive status report
  • uid The user ID.
  • pkid The PKID.
  • IpTarget The final executable setup program file name.
  • ODBC DSN The DSN must be anonymous and named SurferlD. Registry key:
  • VCLoader (REG_SZ) the location of the VCLoader.
  • VCDLL (REG_SZ): The location of the VC DLL source (vcdllx).
  • VCSetup (REG_SZ): The location of the Create VC program.
  • IE driver (REG_SZ): The package file (including NPVC and the redistributable .DLLs).
  • VSrP (REG_SZ): IP Address of the VS.
  • VSName (REG_SZ): Name of the VS.
  • Required Source Headers vcserial.h (local) initialpasswords.h (local) oxregistryitem.h (Ultimate Toolbox)
  • the CreatelnstallExe module has one function:
  • Resources are allocated in the setup control file and the new copy becomes the setup executable for the client.
  • the CreateVcInstall module has one function:
  • the header of the installation file consists of the following data structures: struct MyCabinetHeader ⁇ DWORD dwSignature;
  • the CreateVcInstall module performs the following steps:
  • LPBYTE In-memory image of the Verification Client unique image (VCD structure).
  • DWORD dwVcdSize: Length of the image.
  • Encryption algorithm is symmetric.
  • the key is 96 bytes long. EncryptThelmage can use any reduction algorithm to reduce the key if necessary. Alternatively, key is 16 bytes and is used as is. To determine the actual key length, if bytes 17-96 are NULL, the key is only 16 bytes long.
  • dwSize is a multiple ofBlockSize. Current implementation (6/19/97 version): Uses CAST- 128. The key is a MD5 checksum of the IpKey buffer. Any Block Transformation algorithm can be used instead as long as the key size is 16 bytes or less. (Implementations of MusicMarc utilize CryptoAPI or 56-bit symmetric-key encryption algorithms.)
  • Cryptolnternal is the actual engine. It requires a BlockTransformation derived cipher from the Crypto++ library, but works with any available block cipher.
  • BlockTransformation * A pointer to a preset cipher. The key must be initialized in the cipher engine before passing it to this function.
  • the SurferlD Verification Client Setup Control file has only one module. It does not use MFC.
  • SetupCtri has two threads, a worker unpacking thread and a user interface thread.
  • the user interface thread is the main thread. It creates a status dialog box, which shows the installation status to the user.
  • the worker thread follows the following steps:
  • Unpacking setup distribution 3 Unpacking createvcs (called the Setup Wizard in the user interface)
  • the archive file containing the redistributable files and the Netscape plug-in file is stored in the resource VCDATAWCCONST of the SetupCtri exe, and is copied there by the VC generator.
  • the archive file is a Microsoft CAB file. It is not encrypted. It is generated using the createcabs batch file, which compresses the MFC, CRT and other associated files and the NPVC DLL into one CAB referred to internally as vcconst( ⁇ Vr).
  • the archive file is unpacked locally into a temporary directory.
  • the createvcs program is stored in VCDATAWCXTRA. It is unpacked to the temp directory and executed from there.
  • VCSOURCES The directory to store the CAB files.
  • SYSREDIST The directory containing redistributable files.
  • VCUNINST The directory containing the VC Uninstall program (without debug/release).
  • NPVC The directory containing the VC Plug-in program (without debug/release).
  • VCG The directory containing the Verification Client Generator (command line version).
  • CAB ARC The directory containing the cabarc program.
  • the rebuild batch file expects three parameters: the PKID of the Client record, the user ID, and the filename to create.
  • the SurferlD Administrator automatically invokes the VCG program with all relevant parameters and then transmits the file.
  • the SurferlD Verification Client Creator program has the following modules:
  • the System ID framework is described in the section System ID.
  • the user interface consists of an installation wizard.
  • the wizard has three sheets: l.User authentication. This sheet requests the password and authentication code (defined in the server-side database as initialPasswordl and initialPassword2.)
  • VCCC handles the Verification Client creation and extraction from the resources in the Create VCS executable. Structures struct Signatures ⁇
  • the file library in a Create VC application is stored in a resource file attached to the executable.
  • the resource is called VC and is of type VC.
  • This function does not verify the validity of the file. It merely expands it and decrypts it. Decryption is done using the DecryptTheFile function.
  • MoveFileDelay (LPSTR lpTarget,LPSTR IpSource); This function moves files that are currently open using system-dependent calls. In Windows 95 it adds the files to a registry key that automatically renames them on reboot. In Windows NT it uses the MoveFileEx function. Parameters:
  • LPCSTR Path to the .DLL. This must be the final path for the .DLL.
  • This function installs the Netscape plug-in into the appropriate location. It automatically senses Netscape Communicator, Netscape Navigator, and Internet Explorer and copies the plug-in into the appropriate location. This function invokes the Plug-in Installer module.
  • This function installs the Internet Explorer ActiveX control and copies it to the appropriate location. It is not currently used.
  • Plug-in Install The plug-in installation module handles the registration and installation of any browser (or other program) drivers for SurferlD Client.
  • the current installation module handles installation for Microsoft Internet Explorer and Netscape Navigator by copying the npvc.DLL file to the appropriate directories.
  • This function creates a file called VCDATA.VCD in the target directory based on the cabinet header supplied.
  • the file is encrypted using EncryptThelmage and compressed using the COXCompressor, and signed with MD5.
  • This function calls SetVCDPath to set the location of the VCD file in the registry.
  • This function sets the path to the VCD file in the registry.
  • the registry path is ro EY_CURRENT_USER ⁇ SOFTWARE ⁇ SurferIDWerification ClientWCD Location.
  • the Verification Client Loader is the user executable VC.EXE. It uses various techniques to make it difficult to determine the actual code of the Verification Client, in order to prevent reverse engineering, and checks for the existence of a System ID. It also supplies the user-interface elements for the Verification Client.
  • the Verification Client Loader has these tasks:
  • VCD file will reside in the same directory as the Loader.
  • the Unique data are the k and x values supplied to the genrandO function in the Verification Client.
  • the current genrand() function uses a 100-byte x value and a 4 byte k value.
  • the Unique data comes with a 72-byte header containing locator and user information, raising the actual size of the Unique data to 176 bytes.
  • the primary rule with a Unique data block is that is must be of a size evenly divisible by 16, and must include the 72-byte header including a 16-byte MD5 checksum.
  • a portion or all of the Unique data may be stored on the key itself. In such cases, only the header is saved as Unique data.
  • the Unique data is stored as part of the Shared Secret.
  • the Anonymous Memory-Mapped File The Verification Client is a spawned process of the Verification Client loader.
  • the anonymous memory-mapped file allows secure data transfer between the parent and child processes using inherited handles.
  • the System ID is stored on an external device such as a hardware key and that key has read/write memory
  • some or all of the anonymous memory-mapped file may be stored on that key instead of through the anonymous file. The other precautions may still be used to prevent disassembly and patching to remove the dependency on the key.
  • the user interface is OEM-specific, the components may need to be initialized before the VC is actually loaded.
  • the default Verification Client needs no user interface at all and does not display one.
  • Windows will not run executable files unless they are committed to disk first.
  • the VC core is committed to disk just before it is run, but it is locked to prevent disassembly and duplication.
  • the lock handle is set to delete the file on close. (The VC Core is also encrypted/compressed with Shrinker or a similar at execution.)
  • the Core is currently a .DLL.
  • the anonymous handle is shared between the .DLL and the executable, allowing separation into processes as needed.
  • the Core can be made into an independent executable and the loader replaced, as the two do not share any essential data except through the anonymous file.
  • the Unique data is modified on exit from the Verification Client with a new k and x value. This data is encrypted and placed back in the VCD file.
  • the Verification Client is a client-side module that implements authentication using a separate channel. It does this by relying on a unique System ID which can either be a password, system and user settings, or OEM value.
  • the SDK version of the Verification Client will include the tools needed to replace the System ID generator with a new one. Specifications
  • the Verification Client is a client-side component and as such must be protected against client tampering or replacement. It does this using the following security precautions: 1.
  • the VC Data is never stored on disk except in encrypted form.
  • the VC executable is stored on disk only for the time it is actually executing, during which time it is exclusively locked. This makes interpretation of the EXE very difficult.
  • the VC Loader stores MD5 checksums to the VC executable and VC data.
  • the checksums are used as part of the password for the EXE, making it very difficult to determine how much of it is static data.
  • the Core is the actual verification method. The Core does the following steps: • Opening the Unique Data.
  • the Unique data includes a System ID.
  • the Core periodically checks the System ID against that ID to insure that it has not changed. (This test is suppressed on Clients with fixed IDs that cannot be changed while the program is running, and on those in which the ID is that of an external device which generates the random-number sequence.)
  • the IP address of the Verification Server is encoded in the header of the Unique data.
  • the target port is a fixed port below 1024 and is hard-coded into the Verification Client.
  • the server and client communicate using a proprietary protocol.
  • the handshake sequence begins with the Verification Client sending its serial number to the Server.
  • the Server verifies that the serial number is in valid format and then sends it to the Proxy Server's Verification Subsystem.
  • the Verification Server then returns a status code indicating if access is permitted to this client at this time, and a challenge to the shared secret.
  • the Client If the status code was valid, the Client generates a response XCHG. Only after receipt of a valid XCHG will a client be considered “logged in” and then only until the XCHG sent is not valid. An invalid XCHG is used as a signal to terminate the connection on the client side.
  • the client continues sending XCHG with a preset delay until one is rejected.
  • Each XCHG that is accepted is acknowledged with another XCHG.
  • the connection is closed by TCP close connection.
  • the Unique data is updated at this point with the new k and x values. On systems verified using a hardware key with memory, the Unique data is updated in the key memory. (The data is not updated if no CX_PERSIST commands were sent.) Browser Integration
  • the Client Loader consists of two modules: 1. User interface 2.VC Core Loader
  • the user interface is invisible and subject to each OEM implementation.
  • the Loader contained in the vcslf module, consists primarily of cut-and-paste copies of the System ID modules, EncryptThelmage, and three major functions:
  • UnpackVC opens the VCD file and prepares the environment for the actual launch of the Verification Client core.
  • UnpackVC calls GetSystemID for System ID information necessary to decrypt the Verification Client, and then creates two images ⁇ the core image and the unique image.
  • the unique image is stored in an anonymous memory-mapped file that is shared between the client and the loader. (In future revisions this may be changed to a local memory buffer.
  • the core image is the complete .DLL of the Verification Client, and is written as a temporary file. The .DLL is vulnerable between the calls to UnpackVC and the LoadLibrary call in DoVCReal. Input:
  • DoVC creates a worker thread for the Verification Client.
  • the Verification Client loader itself sits in the DoVCReal function, which eventually calls the VCEntry entry point in the core.
  • the VCLdrWindows structure contains pointers to all of the various windows defined in the user interface and used for feedback.
  • the VCLdrWindows structure is defined as: struct VCLdrWindows ⁇
  • DoVCReal is an internal thread procedure. DoVCReal opens the VCD file pointed to in the registry, unpacks it (using UnpackVC), loads the core contained therein, finds the VCEntry entry point, and passes control to the VCEntry function. After VCEntry returns, the core is freed and deleted and the mapping is deleted. The VCD is updated using Update VCD.
  • the core is deleted before calling VCEntry in the release build.
  • the core is compiled with the SWAPRUN:NET option to allow it to be deleted.
  • UpdateVCD writes new x_values into the VCD file from the memory mapped file. It uses the same algorithm as that used in createvcs. See the actual source for details on the update algorithm.
  • UpdateVCD uses a background thread which is triggered by an event in CxPersist.
  • the event is synchronous and is used instead of a direct call so that thread-local data in the persistence implementation does not affect the actual Client and does not require a specific calling convention, process, context, or location.
  • lpVcdFile The path to the VCD file.
  • HANDLE hMapping: The map handle.
  • the core consists of two main sections: the portable core, and the system dependent core.
  • the portable core is documented in the section SurferlD Portable Kernel and contains the vcp module.
  • the interface between the two sides is defined as:
  • VCHEADER vcHeader DWORD x[25]; // client x variables DWORD serve ⁇ x[25]; // server x variables ⁇ ;
  • Non-portable functions called from portable code
  • VcStartCommunications returns nonzero the Verification Client calls VcShutdown and then exits.
  • the HTTP module is linked to through the implementation-dependent section, therefore that code is responsible for autodetection of supported browser types.
  • the VCP section needs these bits for the server, so it gets them from the VCI component. dwSettings exact value is server-dependent.
  • VcUserPoll If VcUserPoll returns a nonzero integer, the Verification Client calls VcShutdown and then exits.
  • Verification Client Starts up the Verification Client state data and non-portable engine parts. Returns nonzero on error. On receipt of a nonzero integer the Verification Client must immediately exit. VcShutdown does not get called unless VcStartup returned success.
  • the status parameter corresponds to the VCS_* defines below. If this function returns nonzero the Client will call VcShutdown and then exit.
  • VCS_INIT 0 #def ⁇ ne VCS_OPENING 1 #define VCS_NEGOTIAT ⁇ NG 2 #defme VCS_LOGGING_rN 3 #defme VCS_SENDING 4 #define VCS_RECEIVTNG 5 #define VCS SHUTTING DOWN 6 #define VCS_ACCESS_DENIED 7 #def ⁇ ne VCS_COMM_ERROR 8 #defme VCS CONNECTED 9
  • This function converts an IP address in local byte order into a formatted string (dotted octet notation.)
  • the function uses a static buffer and is not re-entrant.
  • This function formats a VC serial number into displayable form (Vcaaaabbbbccccdddd.) Input:
  • GetCurrentMinute returns a 32-bit integer representing the current time in minutes. This is used for random salting.
  • VCI is the state data structure (LPVOID statedata) that is passed in the VCP functions.
  • VCI maintains all state information for the system-dependent Vc* functions.
  • the VCI structure contains the following members:
  • ThreadData * t // The thread data
  • VcStartup is the first function called from the portable implementation. It initializes the state variables and prepares the environment for a connection.
  • VcStartup loads and initializes the interface to the Netscape plug-in.
  • the first parameter is a statedata pointer.
  • This function sets carrier bits in the CRSRESPONSE.deRetFlags parameter.
  • CX_HTTP based flags are dependent on system settings, so the flags must be set by the system dependent component.
  • VcSend (LPVOID statedata,LPBYTE data,DWORD dwSize); This function handles the sending of data in a platform independent manner.
  • the VCI implementation uses the CdebugWsClient.Send() function. The function assumes blocking.
  • VCI uses the
  • VCP kernel will differentiate between CX_HTTP packets and non-CX_HTTP packets by calling CHAHTTP functions for packets marked CX_HTTP.
  • VcStartCommunications starts the OOB channel.
  • VcUserPoll is a event-polling function. If the user indicated that he wishes the process to terminate, VcUserPoll should return nonzero. This function is called frequently as part of the VCP execution, and in particular during each Send and Receive. If VcUserPoll returns nonzero, the VCP will update xs in the VCDATA, call VcShutdown, and then exit.
  • VcStatusCallback (LPVOID statedata,DWORD status); This function is a helper function to allow the user interface to know when something is happening in the VCP kernel.
  • the VcStatusCallback function receives status notifications whenever anything happens in the VCP kernel, and can update the user interfaec accordingly.
  • the notifications are:
  • VCS_ENIT The VCP kernel is initializing.
  • VCS_OPENENG The VCP kernel (with the system-dependent VCI) is opening a comm channel to the Server.
  • VCS NEGOTIATI The VCP kernel is negotiating a handshake with the Server. (This message may not be sent.)
  • VCS LOGGENG I The VCP kernel is logging into the Server. (This message may not apply on ⁇ - ⁇ — an OOB channel.)
  • VCS SENDING Th e ⁇ CP kernel is sending data (including login messages.)
  • VCS RECEIVING e VCP kernel is receiving data (including login messages.)
  • VCS_SHUTTENG_ The VCP kernel is shutting down.
  • VCS ACCESS DE The Server returned an Access Denied error.
  • VCS COMM ERR r ⁇ le comm im k returned a comm error. (Details may be in the VCI already.)
  • VCS CONNECTED T ⁇ Server logged the Client in.
  • VcShutdown (int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits. Note that VcShutdown may also call VcStatusCallback. The output is ignored on a VCS_SHUTT ⁇ NG_DOWN message. void VcShutdown(LPVOID statedata); VcShutdown is responsible for shutting down any state data or communications links maintained by the VCI. VcShutdown may be called at any time after a successful invocation of VcStartup.
  • VcShutdown does not return any value. An exception may be thrown if desired. VCP has no exception handlers, so an exception thrown by VcShutdown will reach the calling function in VCI. (Note that throwing exceptions from other functions may lead to corruption of the VCDATA.)
  • VcPersist triggers a persistent save of the server and client x tables. This is done as an atomic operation during a CX_PERSIST processing. On the client, it is triggered at the next call after a CX_PERSIST flag, to insure the roundtrip. This reduces significantly the probability of a corrupt Client, although does not eliminate it completely. However, if network communications are so unreliable to begin with then persist messages should not be sent to begin with. The final release will not send persist messages if packets can be lost.
  • MainPipeThread is the "shell" that calls the VCP kernel. It contains all exception handlers and the main data flow that surrounds the VCP core.
  • MainPipeThread calls VcStartProcess from within a try block. It contains exception handlers for all exceptions that may be thrown from within VCP. VCP does not generate any user exceptions.
  • AutoDetect is responsible for setting the appropriate bits for Internet Explorer and Netscape Navigator in the ThreadData structure.
  • Loadlnterfaces loads the Netscape Navigator and Internet Explorer interface modules as needed. At the moment only the Netscape module is implemented. Loadlnterfaces initializes the Netscape module by creating a new instance of CNpInterface (see NPVC.) The Internet Explorer interface is ignored.
  • CHAHTTP is the interface that transmits CX_HTTP packets to the Server.
  • CHAHTTP uses an extended CRSRESPONSE format and does not include a challenge.
  • CHAHTTP is not used; VcSend and VcReceive are used instead.
  • class CRSHTTPRESPONSE public CRSRESPONSE ⁇ private: static WORD ConvTable[256]; public: char dwVc Serial [16]; // VC Serial number
  • CRSHTTPRESPONSE :CRSHTTPRESPONSE(CRSRESPONSE & crs); CRSHTTPRESPONSE::CRSHTTPRESPONSE(CRSRESPONSE &crs,CRSPARAMS &p); Both of these constructors expand the CRSRESPONSE structure (a component of the XCHG structure) with additional information necessary to track a stateless single-point HTTP response and identify its origin.
  • SendHttpRequestIe (LPSTR lpIpAddress,LPSTR IpText);
  • SendHttpRequest (CRSRESPONSE & xm,CRSPARAMS & params);
  • SendHttpRequest is called from the VCP kernel to send data through the HTTP interface whenever the challenge has the CX_HTTP flag set. This function may be replaced in implementation clients.
  • the current version does the following:
  • the VCP portable kernel contains the common CHA implementation functions. It is relatively portable, although the actual porting has yet to be implemented.
  • VcSend This function is an internal wrapper around the VCI function VcSend. It takes the same parameters and calls the external function. However, VcSendX also calls VcStatusCallback(statedata,VCS_SENDlNG) after the successful invocation of VcSend to notify the user interface.
  • VcRecvX (LPVOID statedata,LPBYTE data,DWORD dwSize); This function is an internal wrapper around the VCI function VcReceive. It takes the same parameters and calls the external function. However, VcRecvX also calls VcStatusCallback(statedata,VCS_SENDrNG) after the successful invocation of VcReceive to notify the user interface.
  • Vc Wrapper is a "wrapper" default entry point. It is not currently used.
  • VcStartProcess is the entry point for VCP. VcStartProcess does the following: 1. Assigns local variables.
  • VcStartProcess updates the VCD, calls VcShutdown, and then exits.
  • VCD * Pointer to the VCD buffer. This buffer is the "live" buffer with the persistent x variables.
  • Exceptions are not thrown from this function.
  • the function is transparent to thrown exceptions, but does not save x variables if an exception is thrown. An uncaught exception will corrupt the x table and if persistent may invalidate the Client.
  • CHA functions are shared between the Client and Server.
  • the CHA functions are divided into two modules: cha and chasvr. Both are included in Client and Server.
  • This class provides a system-independent critical section. It has no implementation on the Client as the client has only one active thread in CHA.
  • CRSRESPONSE is the response part of the XCHG structure.
  • CRSRESPONSE has the following definition: class CRSRESPONSE ⁇ public:
  • VCRJSTOHTTP 0x04 // no HTTP client is available
  • VCR_UA_IE 0x10 // user-agent should be Internet
  • VCRJ AJSTSCP 0x20 // user-agent should be Netscape
  • VCR_HTTPREQ flags The Server may choose to ignore VCR_HTTPREQ flags.
  • VCR_HTTPRESP packets must be valid only in the HTTP response. The response in the contained packet is ignored. VCR_HTTPRESP packets may only be sent if the challenge was a CX_HTTP challenge.
  • the User-Agent flags are currently ignored except for count.
  • the server will expect one HTTP response for each user agent flag present. If the VCRJNOHTTP flag is set the Server may choose to disconnect the client depending on local policy.
  • CRSHTTPRESPONSE is the response packet for CX_HTTP challenges.
  • CRSHTTPRESPONSE has two forms: text and binary. The functions to convert CX_HTTP challenges from text to binary and back are part of cha. The actual transmission and construction of CRSHTTPRESPONSE packets is left to the VCI.
  • class CRSHTTPRESPONSE public CRSRESPONSE ⁇ private: static WORD ConvTable[256]; public: char dwVcSerial[16]; DWORD dwClientlP;
  • ConvTable is a lookup table of 256 BYTE to WORD mappings.
  • CRSXMITHDR is the challenge part of an XCHG packet. It is defined as: struct CRSXMITHDR ⁇ WORD Flags;
  • CRSPARAMS is the control structure for CHA.
  • CRSPARAMS contains all of the state information that is needed on each side for challenges and responses.
  • serverEP is the IP address to send the response to.
  • flags contains a combination of VCC_* flags used to determine how to send the response.
  • dwVCSerial contains the VC serial number.
  • httplast contains the last received HTTP challenge.
  • chabuf is the persistent x store.
  • chahttp is the HTTP x store. (This buffer may be out of sync with the others if a HTTP response takes a long time.)
  • chawks contains the current workspace. This buffer is synchronized on a
  • bitmask contains valid bits on the challenge. Only bits that are on in this mask are used in the actual challenge. This prevents overloading a simple machine that can't handle complex iterations.
  • timeout contains the timeout for a specific client on a server. It is not used on the client. bufk is the k value for the chabuf. It is not persistent. httpk is the k value for the chahttp. It is not persistent. wksk is the k value for the chawks. It is not persistent.
  • This function creates a simple checksum in the garbage bits of the challenge and is used to prevent against packet corruption where relevant.
  • the function is implementation dependent and must be the same on client and server.
  • BOOL CRSXMITHDR Verify Checksum(void); This function checks the checksum created by MakeChecksum and returns TRUE/FALSE on equality. The function is implementation dependent and must be the same on client and server.
  • WORD CRSHTTPRESPONSE :byteToWord(B YTE i);
  • This function converts a BYTE to the WORD printable representation using the reverse algorithm.
  • the function uses a simple lookup table.
  • the lookup table is stored in the static member ConvTable, which is initialized by a call to InitConvTable on the first invocation of byteToWord.
  • This function converts the CRSHTTPRESPONSE data to a portable 7-bit text unescaped string representation.
  • the string is 115 bytes long and consists of a three byte header followed by a 56 WORD representation of the byte pattern of the CRSHTTPRESPONSE in little-endian unpadded order, converted using byteToWord.
  • the first three letters are "ACK", which are all illegal bytes in the byteToWord conversion algorithm.
  • ConvertToString also updates the MD5 localsign member with the current checksum. Return value:
  • ConvertFromString converts the inputted string into this. The following validations are done:
  • This function initializes the CHA module. It does the following:
  • CreateChaReq creates a challenge and verifies the response to the previous one. CreateChaReq follows the following steps if the last pointer is not NULL or invalid (which implies that this is the first challenge and does not need to get verified):
  • CRSXMITHDR * Buffer to place the new CRSXMITHDR. This must be valid. On error, the contents of this buffer (not the pointer itself) will be zeroed out.
  • CRSPARAMS & The CRSPARAMS state data. This will contain the Server state on the Client side.
  • ProcessChaReq processes CHA challenges and produces responses. This function may be called in the context of verifying responses or in the context of generating them in the first place.
  • NPVC is a Netscape and Internet Explorer compatible plug-in that facilitates the transmission of CXJETTTP packets and adjusts the cookie stream accordingly.
  • the plug-in must be present for a browser to be verified as a user of SurferlD.
  • NPVC communicates with the VC core using a shared memory mapped file. This is not secure but is portable to Windows 95, which does not support local named pipes.
  • NPVC consists of two modules: the CNpInterface class, which is implemented on the client and plug-in and handles communications, and the NPCORE module, which handles the actual plug- in interface.
  • CNpInterface the CNpInterface class, which is implemented on the client and plug-in and handles communications
  • NPCORE the NPCORE module
  • CNpInterface has the following structure: class CNpInterface ⁇ public: struct NpData ⁇ int MsgNumber; int pid; BYTE url[512];

Abstract

A system for authenticating two peers within an authentication protocol. The peers are associated with a shared secret common to the peers and an identical randomization agorithm that utilizes a pseudorandom generator. In response to a command received from a challenging peer from among a challenging peer from among the two peers, the other peer (constituting a challenged peer), applying the randomization algorithm seeded by the shared secret so as to obtain one or more outputs. The challenged peer applying transformation to the output and to data of packet so as to obtain a response. A transmitter transmitting the packet and the response to the challenging peer. The challenging peer applying the algorithm and compares the so-obtained response to that received from the challenged peer and in the case of match the challenged peer is authenticated.

Description

Method and System for the Protected Distribution of Network Files
Field of the Invention
This invention comprises a method and system for the protected distribution of network files.
Background of the Invention
Network File Distribution Many communications networks are currently engaged in the distribution of files. These files may contain text, numerical sequences, audio or video contents, graphics, hypertext, or other content. Often this content consists of confidential information or legally registered property. As communications networks increasingly interconnect to form file distribution cooperatives of uncertain geographic extent, opportunities to surreptitiously copy file contents become more available. This has a deterrent effect on the utilization of such networks, and certainly prevents them from becoming a viable conduit for electronic commerce. The online distribution of digital music files provides an excellent example of the problems encountered in the attempt to achieve secure file distribution, as well as the concepts related to network distribution in general. Digital Music Distribution
Music is primarily sold to the public in the form of compact discs (CDs). CDs are mastered with a digital recording of music at 44,000 samples per second in stereo. Each CD holds a maximum of 660 megabytes of data, or 74 minutes of music. At current transmission rates (assuming a clean 56k connection of 7 kbps), it would take 26 hours for a user to retrieve a CD recording over the Internet.
To allow transmission of music in a more practical manner, two methods were devised, streaming and image recording.
Streaming and Image Recording
In a streaming method, a fixed transmission rate is combined with an unreliable transmission method. Streaming sound sources are broadcast at a compression ratio that ensures that an approximation of the sound will be heard at the receiving end if the user receives all of the packets in their correct order (packets are discrete units of data transmitted over the wire). However, streaming does not guarantee that all packets will be received in order, a drawback that can cause transmission delays. Streaming is primarily used by Internet radio stations, which do not expect the user to save a recording of the stream. Streamed sound is comparable in quality to an FM radio station under normal network conditions in a dialup 56k environment.
Image recording copies the image (file) of a track from a CD and compresses it for future use. The compressed file is not intended to be streamed in real-time, and generally takes considerably longer to retrieve than the actual playback time. MP3 is a merge of these two concepts. An MP3 (MPEG-1, Layer 3) file is an image of a stream format, which is converted to a stream at relatively high bandwidth. MP3 conversions of 128 kbps can achieve CD-quality recordings, which can theoretically be streamed over a dual ISDN line, although some forms of music require the higher 192 kbps to achieve proper fidelity. An MP3 file is compressed at a ratio of 12:1 to 14:1 for maximal output performance, although it can be compressed to up to 96: 1 if quality is not important. This is similar to the ratios of JPEG files for images, where image quality is degraded by high compression ratios.
The following explanation of the MP3 file format was taken from the Fraunhofer Institut Integratierte Schaltungen website. Fraunhofer IIS developed the first commercial encoder for MPEG file formats.
Fraunhofer IIS and the development of MP3 In 1987, the Fraunhofer IIS started to work on perceptual audio coding in the framework of the EUREKA project EU147, Digital Audio Broadcasting (DAB). In cooperation with the Prof. Dieter Seitzer at the University of Erlangen, the IIS finally devised a very powerful algorithm that is standardized as ISO-MPEG Audio Layer-3 (IS 11172-3 and IS 13818-3). Without data reduction, digital audio signals typically consist of 16 bit samples recorded at a sampling rate more than twice the actual audio bandwidth (e.g. 44.1 kHz for compact discs). The result is more than 1.400 kbit, representing just one second of CD-quality stereo music. MPEG audio coding shrinks the original sound data from a CD by a factor of 12, without losing sound quality. Factors of 24 and even more maintain a sound quality that is still significantly better than that received by simply reducing sampling rate and resolution. This is realized by perceptual coding techniques that imitate the perception of sound waves by the human ear. Using MPEG audio, one may achieve a typical data reduction of
• 1 :4 by Layer 1 (corresponding to 384 kbps for a stereo signal),
• 1 :6 - 1 :8 by Layer 2 (corresponding to 256-192 kbps for a stereo signal), and • 1 :10 — 1 :12 by Layer 3 (corresponding to 128-112 kbps for a stereo signal), while still maintaining the original CD sound quality. By exploiting stereo effects and by limiting the audio bandwidth, these coding schemes may achieve an acceptable sound quality at even lower bit rates. MPEG Layer-3 is the most powerful member of the MPEG audio coding family. For a given sound quality level, it requires the lowest bit rate - or for a given bit rate, it achieves the highest sound quality.
See Figure 1
In all international listening tests, MPEG Layer-3 proved its superior performance, maintaining the original sound quality at a data reduction of 1 :12 (around 64 kbit/s per audio channel). If applications tolerate a limited bandwidth of approximately 10 kHz, a reasonable sound quality for stereo signals can be achieved even at a reduction of 1 :24. The ITU-R (International Telecommunication Union - Radio Communication Sector) recommends the use of MPEG Layer-3 for low bit-rate audio coding schemes in broadcast applications at bit rates of 60 kbit/s per audio channel (ITU-R doc. BS.l 115).
It should be noted that Fraunhofer has patented the techniques for decoding MP3 files; however, licensed decoders are freely available. Ripping
Ripping is the procedure used to convert a CD track into an MP3 file. Ripping itself is not illegal, and neither are the tools necessary to rip a CD; only the actual redistribution of the "ripped" file is illegal. Ripping for redistribution consists of three steps: l)Reading the CD track. 2)Encoding the CD track into MP3 format. 3)Uploading the MP3 file to a distribution server.
Reading Reading the track can be accomplished using any of a large number of utilities. For illustration purposes, we have chosen the CDCopy program, which is a full-featured CD reader. CDCopy can retrieve tracks from CDDB servers and lyrics from lyric servers (CDDB is a freeware server of CD and track titles that can be automatically matched to CDs. Lyrics servers allow matching a CD track title to its lyrics).
See Figure 2
The system automatically outputs WAV files, which are uncompressed images of the sound on the disk and are typically 20-80 megabytes each. Track information in this illustration was retrieved automatically from a CDDB server and lyric information was retrieved from a lyric server. All of these programs and services are free to the online community (CDCopy is only free for a limited trial period).
Encoding
Encoding the track can be done using the same program. In this illustration, the file we ripped, Centerfold from J. Geils Band, is about to be converted into MP3 format. The options allow different degrees of compression and sound quality; the preset format converts the WAV file recorded from a CD to an equivalent quality MP3 format.
The original WAV file was 38.8 megabytes. The compressed MP3 file is 3.5 megabytes. The following illustration shows what the file looks like when played on a freely available MP3 player: WinAmp.
See Figure 3
Uploading
Uploading the file is done using a standard FTP client. Our illustration was done with a local FTP server owned by MusicMarc, but the distributor of illegal music will generally post to a public access FTP server. The program used is CuteFTP, which is a commonly used and recommended FTP client.
See Figure 4
It should be noted that not all distribution methods require FTP uploading of the music track. The most popular delivery mechanisms are remote HTTP/FTP and SMB.
Remote HTTP/FTP
HTTP (HyperText Transfer Protocol) is the "language" of the World Wide Web. HTTP requires the use of a standard web browser, and is very user-friendly. To publish a file to an HTTP server, one needs an account on a matching FTP server or a publication system such as Microsoft FrontPage. FTP (File Transfer Protocol) is an older protocol than HTTP, designed for the efficient transfer of files. FTP requires a program known as an FTP client. Web browsers can work with FTP servers, but due to the constraints of most illegal servers a web browser is not considered efficient and may be blocked by the server. A remote server is the usual means of "trading" MP3 files. One person rents space on a public-access server or publishes his own computer (typically through a cable modem) to the Internet, and encourages other users to publish files to the server. Generally, the server operator will place a large initial collection of MP3 files on the server, to encourage traffic. Retrieval (or downloading) of the files is generally subject to the "ratio" system, wherein a client who wishes to download an MP3 file from the server must first send (or upload) an MP3 file from his own collection, and may only download a certain number of files for each file uploaded.
SMB
SMB (Server Message Block) is a component of Microsoft's Common Internet File System (CIFS), a project that has seen few results other than in this community. CIFS uses the Windows networking file system to publish files to the Internet. ScourNet, a popular MP3 portal, uses SMB to index and publish files from users who do not wish to use the complexity of FTP or HTTP publishing. These files remain on the user's computer and can be downloaded using the ScourNet Scour Media Agent client. SMB is an open standard and may be implemented by other search engines in the future; at the moment only ScourNet has done so.
Catalog Sizes and Estimated Loss
A search for the pattern "Centerfold" was conducted on the several common search engines for MP3 files, yielding the following statistics (the local server used for testing is not on any of these engines, nor available to the browsing public).
See Figure 5 The music industry, represented by the RIAA, ASCAP, BMI, and the Harry Fox Agency, have reacted strongly to the loss of revenue caused by illegal redistribution of copyrighted works on the Internet.
The following efforts have been made to address the issue of illegal reproductions of music.
• Legislation. The industry has lobbied US and European governments in an effort to increase the liability of those involved in illegal distribution. This has met with strong opposition by privacy groups, Internet service providers, and other interest groups. Furthermore, it is unclear how strengthening laws against what is already an illegal activity would discourage lawbreakers, unless these laws sanctioned more aggressive enforcement than that accepted by democratic countries.
• Search engines. The industry has created a number of search engines that attempt to find MP3 archive sites, in an effort to close them down. Unfortunately, due to the anonymity and globalization of the Internet it is very difficult to trace a site and determine its ownership. This is especially true in the field of MP3, which is primarily run by hobbyists who do not post any form of identification and are not seeking payment for their services. • Technological advances in music distribution. Liquid Audio and Intertrust, among others, have produced competing standards for secure, legal music distribution. Liquid Audio supports watermarking technology that allows reproductions of Liquid Audio tracks to be traced across the Internet. • Cooperative projects to create copy-protection standards for music. In September 1998, the Secure Digital Music Initiative (SDMI) was formed to create and maintain standards for secure storage, transmission, and playback of music. MusicMarc, Liquid Audio, and InterTrust are all active SDMI members. Existing Industry Solutions
Liquid Audio
Liquid Audio is partially owned by Intel. Partners include major names in the online music industry, including Music Boulevard and Billboard. The Liquid Audio Network claims to have 1500 artists.
Liquid Audio uses a multi-pronged approach including watermarking, encryption, and a special server format. LA tracks must be mastered using a special encoder on the server, streamed using a special server, and then played using a proprietary player. Tracks are eO using Dolby Digital encoding (which can compress up to 176:1), and low-quality preview tracks are created automatically. Non-musical information can be added to the stream, including liner notes, lyrics, pictures, etc. The encoder sells for $295. LA requires a Music Server as well, which includes full database connectivity, music services, online watermarking and adjustable streaming rate. Music Server reports royalties to copyright holders and tracks sales automatically, and is a full end-to-end solution.
The player, a free application called Liquid Player, allows secure storage and mastering of CD-Rs based on the purchased content. Only one CD can be mastered from each song in a locally cached collection.
Liquid Audio controls the key information necessary to purchase music via the Music Passport. Furthermore, LA has an "Operations Center" which controls royalty reporting. Although not clearly stated in the website, it appears that LA receives a fee for each track sold. Furthermore, there are "merchant certificates" that need to be purchased (apparently from Liquid Audio) and the server will only work with valid certificates. The server price was not disclosed on the site and is not available from third-party dealers. Disadvantages of Liquid Audio
• Liquid Audio requires a proprietary encoder.
• Users require Liquid Audio's decoder. They cannot use WinAmp or similar freeware players or integrate with existing packages. • Liquid Audio entails possible privacy infringements due to its central server that tracks undisclosed information. No clear privacy statement is available.
• The use of restricted encryption impedes international growth. (Note that Liquid Audio does not restrict export of the player, implying that the key is weak enough to allow export, and can therefore be compromised.)
• Liquid Audio's integrated purchase system opens users to potential fraud.
• Streaming-only sample architecture can reduce sample quality.
Advantages of Liquid Audio
• Encrypted files cannot be exchanged. • The integrated solution includes a commerce solution.
• Liquid Audio allows integration of promotional video and liner notes.
(MP3 allows this but few if any decoders support it. However, it should be noted that generally all promotional material is available on the artist's web sites anyway and that lyrics are available through the International Lyric Server, so someone who really wants to reproduce the promotional material can do so.)
• Liquid Audio's compression format may be more efficient than MP3.
• Liquid Audio provides a comprehensive turnkey solution.
Architecture See Figure 6
Note: This table presents only a sample of MP3 search engines. Samples taken July 19, 1998. 6.1 Encoder System: Utilizes a tool called Liquifier Pro, which masters the initial copy of the tracks into a proprietary compressed/encrypted format ("Liquid Tracks").
6.2 Music Server: A proprietary integrated web server and streaming server that transfers encrypted Liquid Tracks to customers and tracks sales to an external Tracking Database. Music Server also reports on each sale to the Operations Center at Liquid Audio.
6.3 Operations Center: An online center operated by Liquid Audio that tracks sales, royalties, and ownership of each track supported by Liquid Audio. The Operations Center also reports royalty statements automatically and acts as a Certificate Authority.
6.4 Liquid Player: A proprietary decoder for music that allows controlled playback of purchased tracks, which remain encoded and watermarked. Liquid Player also supports lyrics and promotional material.
6.5 Music Passport: A local client certificate that allows tracking and decoding of music tracks by the authorized user and can be used to purchase tracks online.
Intertrust InterTrust describes its Business as providing "Software and services for selling intellectual property securely over the Internet." Its software stores valuable files and governing rules in container-based, encrypted data files called DigiBoxes. Each person who downloads these files can pass it on to another, under the same rules about payment and copying. PC users need a special piece of InterTrust software, which is expected to be widely distributed for free.
Although InterTrust is not providing an end-to-end digital distribution system alone, it does want to be the center of a consortium of companies that will provide completely integrated digital-distribution systems for any kind of content, including digital music downloads.
InterTrust's business model proposes the licensing of a group of companies that will have the right to provide products, services and integrated solutions in a global e-commerce model called the "MetaTrust Utility". InterTrust will not compete with the MetaTrust participants, instead it envisions itself in the role of a utility (i.e., natural monopoly) that will serve in a "truly neutral capacity" to establish and maintain trust among content owners, distributors, service providers, clearinghouses, distributors, retailers, and consumers. Through its technology and leadership, InterTrust will assist in assuring ongoing interoperability, security and trust between the different MetaTrust licensees.
InterTrust claims to hold a number of patents related to content distribution and security. InterTrust is of the belief that these patents are a barrier to entry for other participants.
Unlike some of its competitors, InterTrust is not one of the security providers supporting the continuance of traditional business models, in which record companies retained tight control over content and vendor partners. Instead, it has been an evangelist of "superdistribution" and "viral marketing," i.e., consumers becoming participants in product marketing and fostering "pass along" sales.
InterTrust is a provider of generic systems for information security extending beyond the Enterprise to Extranets (Enterprise Edition 1.2), as well as commerce systems for digital information products (Commerce Edition 1.2). We will not discuss these in detail, but will mention another product, the MP3Plus Authoring Application Developer Kit. According to the InterTrust Web site, using the MP3Plus Kits one can: » Market, sell, and fulfill music — from singles to compilations — over the Internet, e-mail, DVDs, and CDs. • Integrate and persistently protect the artistic integrity of music, video still images, text, and graphics in a single multimedia Internet-ready product.
• Enable pass-along distribution between fans, know who they are, and get paid by new listeners. • Create powerful merchandising, promotion, direct response marketing, and affinity groups.
• Receive timely financial payments and usage information for your music.
• Enable your MP3 player for rights management.
• Support and respect music label policies. The kits include both security and Digital Rights Management (DRM) functionality: a sample MetaTrust-certified MP3 player, sample music multimedia DigiBox® containers (the trusted InterTrust security technology) and business model templates, a Commerce Modeler™, Layout Editor, Packager, and Rights Wallet™.
Conclusion
It would be of great economic benefit to the all industries based on the sale and distribution of copyrighted or proprietary material (which may be distributed via a network) if there was a secure method for protecting these materials from surreptitious copying both during transmission on the network and thereafter.
Summary of the Invention
The purpose of this invention (hereinafter "MusicMarc") is to prevent unauthorized reproduction of data during its transmission on a network, and unauthorized distribution of the data after it has been received. It is designed to provide maximum transparency of use to authorized users, while presenting maximum difficulty to those who attempt to use it illegally. The problem of unauthorized reproduction during transmission is technically unrelated to the problem of unauthorized distribution. Both problems must be solved in order to provide the security required by the growing demands of electronic commerce. MusicMarc solves each problem separately, and incorporates the solutions into an integrated system capable of meeting these demands.
File Protection During Transmission
MusicMarc protects a file during transmission by the following method:
• authenticating two peers as will be explained in greater detail below; • dividing the file into first order series of packets at the first peer side;
• applying a reordering algorithm to the first series so as to obtain a second order series of packets; said reordering of algorithm utilizes one or more of said outputs or derivatives thereof;
• transmitting said packets according to the second order series; • receiving the packets at the receiving peer side;
• reordering said packets into the original first order using said outputs or derivatives thereof; and
• using said file.
Consequently, unauthorized interception during transmission will yield a randomly scrambled file.
File Protection After Transmission
MusicMarc prevents unauthorized reproduction of a transmitted file by the following method: (a) chaffing selected packets of said first or second order series of packets;
(b) in the receiving side, undoing said chaffing whilst using said file on- the- fly.
Consequently, unauthorized distribution will result in a file rendered unusable by unfiltered noise. There is further provided in accordance with the invention: (a) deriving at least one chaff key from at least the COA section or portion thereof; (b) chaffing selected portion of said data section using said at least one chaff key.
Peer Authentication
"Surfer ID" is a method for authenticating two peers wherein the authentication protocol is reciprocal and based upon a shared secret key derived from a random seed on the peer's designated Server for that side of the algorithm. The method includes the following steps:
(a) in response to a command received from a challenging peer from among said peers, the other peer, constituting a challenged peer, applying said randomization algorithm seeded by said shared secret or derivative thereof so as to obtain one or more output; (b) the challenged peer applying transformation to at least said output and to data of at least one data packet so as to obtain a response; (c) transmitting the at least one packet and said response or derivative thereof to said challenging peer;
(d the challenging peer applying said algorithm as stipulated in steps (a) and (b) and compares the so-obtained response to that received from the challenged peer and in the case of match said challenged peer is authenticated.
The invention further provides for a system for authenticating two peers within an authentication protocol, the peers are associated with a shared secret common to said peers and an identical randomization algorithm that utilizes a pseudorandom generator, the system comprising:
(a) in response to a command received from a challenging peer from among said peers, the other peer, constituting a challenged peer, applying said randomization algorithm seeded by said shared secret or derivative thereof so as to obtain one or more output; (b) the challenged peer applying transformation to at least said output and to data of at least one data packet so as to obtain a response;
(c) transmitter, transmitting the at least one packet and said response or derivative thereof to said challenging peer; (d) the challenging peer applying said algorithm as stipulated in steps (a) and (b) and compares the so-obtained response to that received from the challenged peer and in the case of match said challenged peer is authenticated.
Still further the invention provides for a system for chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section, the system comprising:
(a) a module for deriving at least one chaff key from at least the COA section or portion thereof, (b) a module for chaffing selected portion of said data section using said at least one chaff key. The invention further provides for a system for de-chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section; selected portion ofsaid file being chaffed by at least one chaff key derived at least from said COA section or portion thereof, comprising
(a) deriving the at least one chaff key from at least the COA section or portion thereof; and
(b) de-chaffing said selected portion using said at least one key.
There is further provided a memory medium storing data identifying computer executable program for accomplishing any of the aforementioned method steps.
Implementation Details
• The First or Second Key includes or is derived using at least one item from the following list: receiver's name, receiver's credit card number, receiver's bank account number, receiver's address, a system signature, a bio-metric signature, a digital signature, or a common datum.
• The Second Key includes information specific to the file-receiving side.
• The first or second randomization algorithm is selected from the list: RSA, DES, Mersenne Twister, MD5 hash, a cipher algorithm, a one way hashing function, a shared secret dependent function, a two way encryption function, a pseudo-random number generation function.
• MusicMarc files are watermarked. Watermarks are concatenated or convoluted at the file-sending side, prior to transmission, and at the file-receiving side following transmission, according to the First Key algorithm. Upon receipt by the Client, watermarks are chaffed according to the Second Key algorithm.
• Files contain content interpretable as music, text, graphics, video, hypertext, or multimedia. According to significant variation embodiments the file is compressed or encrypted. Hereinafter, aspects of an embodiment of the method of the present invention wherein music is the file content will be referred to as "MusicMarc".
• The noise signature used as chaff is implementation dependent.
• The present invention relates to a system for the protected distribution of a file over a network, said network having a first and a second computer device interfaced via an inter-mediating communications network, and a file transfer protocol provided therein, wherein the computers of the system substantially execute the steps of the method as herein described.
Summary of a Preferred Embodiment
MusicMarc is designed to address a need in the music industry, the need to provide a sales and copyright protection infrastructure for the World Wide Web. In the previous pages we have presented an analysis of the technology behind music distribution on the Internet, of the "MP3 Phenomenon," and of current efforts by the music industry and its technological partners to control the distribution of musical tracks.
MusicMarc relates to "Secure Online Music Distribution" in the context of the present invention. In order to understand the invention and how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to accompanying drawings, of which 39 sequentially numbered presentation charts are herein appended for use in summarizing the key elements of this embodiment. Architecture See Figure 7
7.1 Media Server: The existing MP3 server is a WWW, FTP, or SMB server containing MP3 recordings of media artists, including all standard ones available today through the pirate channel. The MP3 server does not need to be restructured except in location, where it will be behind the SurferlD Server and inaccessible to the Internet.
7.2 SurferlD Server: The SurferlD Server filters and authorizes relevant connections to the Media Server. It selectively allows FTP RETR retrievals, WWW GETs and SMB file copy operations based on the SurferlD authentication algorithm. Files designated as licensed are transferred through the SurferlD authentication channel only.
7.3 The Billing Server: The Billing Server logs connections to the Media Server, and handles accounting vis-N-vis the copyright holder. Transactions between the Media Server and the client are not tracked by the Billing Server, but the Billing Server notes some characteristics of each transaction that takes place and assists in financial transactions. The Server may charge the client independently. The Billing Server does not track the name or private information of the purchaser, and can be used in multi-level environments in which the client-server transaction does not take place at the retail level.
7.4 SurferlD Media Client: The SurferlD Media Client uses SurferlD and a standard web browser to retrieve files. Purchase is done securely through any independent means - SurferlD does not handle financial transactions directly. Files are retrieved through the SurferlD authentication protocol as payload stream packets (using an extension to the SurferlD protocol) and are watermarked using licensed watermarking technology. Files are also encoded with chaff on the client, limiting playback to the machine to which they were downloaded. 7.5 The MP3 Player: Marked MP3 files may be played by the client as often as desired and may technically be uploaded to pirate servers and redistributed. However, they will be marked with the watermark of the purchaser and may be scoured by Net search agents. Only a standard MP3 player is needed to play the MP3 files.
Technologies
SurferlD
SurferlD is used to authenticate the connection between Client and Server. SurferlD provides an open interface to all methods of Client authentication in a Server-independent manner. SurferlD is a system-independent one-to-one authentication system utilizing shared secret authentication and a proprietary protocol based on open standards. SurferlD offers a lightweight, portable Client that can be embedded into applications and devices. SurferlD is positioned as the Internet equivalent of Caller ID in telephony applications, allowing full user identification in every connection to the Server.
SurferlD is based on the proprietary CHA protocol developed by Focus Communications Ltd. and licensed to MusicMarc Corp., which provides dynamic continuous authentication for remote-access capable devices and networks. The existing SurferlD technology is used as a base for the authentication engine. The following extensions to SurferlD are required:
1. Server trust relationship
2. The authentication channel as a file transmission channel. 3. Watermarking
4. Interface to a chaff engine
5. Encryption
6. Financial Transactions
Server trust relationship The Billing Server will maintain a separate SurferlD authentication session with the Media Server and will debit an account when the Server reports a successful download of an MP3 file. The Client will also notify the Billing Server to prevent Servers from blocking notification.
See Figure 8
The authentication channel as a file transmission channel.
Secured files above a certain size will be transferred through the authentication channel to authenticated users and will not be transferred otherwise. Transferred files will be "chaffed" using MusicMarc chaffing technology (See the section on chaffing for details). In this case, SurferlD will filter content such that "anonymous" users can browse freely any part of the site, but will not be able to access media files, except as determined by the Billing Server. Unauthorized users will receive either a "demo" file from an alternative source (as defined by the Server or the Billing Server) or will be denied access entirely. The Billing Server will not receive information about which user purchased the file, only that the file was purchased. Watermarking
MusicMarc may use licensed technology from a watermark patent holder to watermark received files on the Client. Watermarking on the Client prevents sales information and Client usage information from reaching the Server unless the Client violates his license and redistributes the file.
Interface to a chaff engine
Chaffing technology will prevent a watermarked file from being easily copied without the use of encryption. A "chaffed" file will have a deliberately introduced carrier waveform that corresponds to the SurferlD of the user. The carrier waveform will be overlaid on the music waveform. A file driver will seek the waveform in each output stream, and will remove it if it matches the SurferlD of the user.
"Chaffed" MP3 files can be played on hardware devices using a licensed chipset only. The chipset will include suitable means of transfer and identification via the host computer or a SurferlD-supported Client verification driver.
Files mastered onto a CD will be "de-chaffed" using a supplied CD-mastering tool. The watermark will remain, and users may use the CD-mastering engine to convert chaffed files into standard watermarked MP3 files if they recreate MP3 files from the CD.
Encryption
Encryption is not used as a primary tool in the SurferlD Media Server for the following reasons:
• Many countries regulate encryption. A truly international product is limited to encryption that is too weak to use effectively.
• Encryption is processor-intensive. MP3 decoding is a processor intensive activity by itself without adding a cryptographic engine. • Encryption does not provide accountability. A decrypted file can be freely reused and is not traceable. Watermarking is impossible to remove without damaging the underlying file, while the use of the authentication channel as a file transmission channel makes it difficult to reconstruct a valid MP3 stream from a "sniffed" session. While encryption can be added to the process, it would not contribute to security. It should be noted that in all cases a file can be intercepted at the device level while it is being played and reconstructed into an anonymous sound file unless watermarking is used. Encryption has a place in SurferlD Media Client in the following areas:
• The Client itself uses encryption internally (when allowed by the country) to protect itself from reverse engineering. This encryption is limited exclusively to the user identification and the associated executable code, and licenses for this encryption may be easier to obtain than for the generic encryption of messages.
• Accounting and billing can be done using HTTPS, and authentication can be augmented using a digital certificate. However, due to the inherent weakness in most digital certificates this is not recommended as a sole means of identification.
Financial Transactions
SurferlD will not provide the necessary infrastructure for SET or other financial transactions, as micropayments on the level of licensing a single track do not justify the overhead of a SET based system, and many alternative business models not involving financial transfers on the track level may be utilized using the technology.
Independently, a licensed Media Server receives a specific license for each file, which may have a value attached to it. A reported sale allows the Billing Server to debit the account of the Media Server, and charge the Media Server at the end of a billing cycle.
Furthermore, a number of large repositories will be constructed (see Deployment Architecture) allowing centralized storage of MP3 files offered by record companies.
Chaffing
Chaffing is the superimposition of a unique numerical value on a designated percentage of the frames composing a digital audio file, creating audible distortion on the file. Chaffing secures a file by allowing only one authorized device, that capable of generating the correct dechaffing key, to filter the chaff off a given file for play. Chaffing also protects the integrity of the COA; as a functional component of the dechaffing process, the COA cannot be tampered with.
Implementation When the user first receives the full MusicMarc Authorization Request Client for installation, it is accompanied by a numerical value generated randomly by the Server. Called the System Key, it is transformed algorithmically with each ping passing between Server and Client.
• The first packet to be transmitted is the COA. The current System Key at the start of transmission is designated the Temporary File Key, and is stored in a temporary database within the Client.
• Before the actual file is transmitted, it is broken into packets of frames, which are then algorithmically scrambled using the Temporary File Key and uploaded out of order. • The existing System Key when the first packet of song frames begins transmission is called the Song Key. It is stored in a temporary file in the host PC's memory, and used to chaff the scrambled file at random intervals during transmission.
• Each time the connection between Server and Client is interrupted during transmission, the Song Key is replaced by the current System Key. In this manner, the chaff on an incoming file is constantly changing.
• The current Song Key when transmission is completed becomes the Final
Song Key, which is stored in a Chaff Database (CDB). The Final Song Key is used to chaff the full scrambled file.
• The Temporary File Key is used to unscramble the file, which is still chaffed by the Final Song Key.
• The Client assembles the key sources required to generate the final chaffing key. These sources include the Final Song Key, the COA checksum (see 1.3.5), the song's rights in binary flag format, and any other elements established by the Server prior to transmission. At this point, the file is protected with a unique chaffing pattern (with the exception of the designated clear header), which can only be filtered using the data stored in the host Client's CDB in conjunction with the Surfer ID.
Certificate of Authenticity (COA) and Chaff Database Integration
The Chaff Database (CDB) resides within the MusicMarc Authorization Request Client on the host PC. The CDB contains the data necessary to generate chaffing keys for all transformations of MusicMarc-enabled audio files authorized by the COA rules (that is, chaff transformations for a portable device or portable media).
The CDB contains a checksum derived from the COA of each file, which constitutes a primary source for the chaffing key. If the COA of a given file contains a different user's Surfer ID, or is tampered with, the CDB will generate a chaffing key that doesn't match the chaff on the file, and the user's audio player will run a chaffed file. Goals
The SurferlD Media Server architecture is targeted at the music industry, and provides a legal alternative to the current situation wherein recordings, implemented in MP3 files, are freely available from various servers without any accountability. The SurferlD approach includes the following points:
1. Non-invasive: Existing sites do not need to be modified to utilize the Media Server. MP3 "catalogs" can be retrieved using the existing search engines and retrievals can be initiated in the standard manner. Only the actual transmission of MP3 files is done through the Client, which intercepts the file transfer request at the Server and Client levels.
2. Client-friendly: Unlike competing encryption-based products, the Media Client allows the user to continue to use his favorite MP3 player and allows offline playing of standard files.
3. Pervasive: As soon as a file is marked with a watermark, it can be tracked throughout the Internet and beyond. While pirate servers will still exist, it will become more profitable and secure to license recordings.
4. Compatible: We use existing technology for all functions. Rapid deployment is possible because all components already exist as prototypes (in the case of SurferlD) or third-party implementations.
Deployment
See Figure 9
9.1 Master file servers: Store the original MP3 files. These servers are heavily secured and MP3 files cannot be retrieved directly from the servers.
9.2 Catalog Server: Tracks and catalogs all of the MP3 files. Users can request specific music files by browsing the database/web server. However, the database/web server does not actually contain the MP3 files.
9.3 SurferH) Server: The hub of the system. All users are allowed to access the Catalog Server, and specific users (depending on their SurferlD and account status) are allowed to retrieve or post files to the master file servers.
9.4 Accounting/Billing Server: Tracks royalties and payments. For a user to retrieve a file, the Accounting Server must authorize the download. The Billing Server allows smaller servers to clear their royalty payments. 9.5 SurferDD Client: Utilizes a universal identification system. Different levels of security and identification are available as supplied by the
Server administration. Each Client includes the watermarking module and a noise-cancellation system that allows playback of MP3 files locally.
The result is that end users can purchase MP3 files online.
Brief description of the drawings
For a better understanding, the invention will now be described by way of example only, with reference to the accompanying figures, in which:
Figure 1 illustrates MPEG Layer-3 Performance Data. Figure 2 illustrates The CDCopy User Interface.
Figure 3 illustrates The WinAmp User Interface.
Figure 4 illustrates The CuteFTP User Interface.
Figure 5 illustrates Search Results for the Pattern "Centerfold."
Figure 6 illustrates Liquid Audio Architecture. Figure 7 illustrates MusicMarc Architecture.
Figure 8 illustrates the Trust Relationship.
Figure 9 illustrates Music Marc Deployment Architecture.
Figure 10 illustrates Known Attacks. Figure 11 illustrates SurferlD Components.
Figure 12 illustrates VCD Structure.
Figure 13 illustrates the Queue.
Figure 14 illustrates the MusicMarc Client Component Map.
Detailed Description of a Preferred Embodiment
Definitions
Terms
Certificate is an implementation defined data block that is inserted immediately following the header. The Certificate is composed of XML fields. Some of these fields are supplied by the Server and some are supplied by the Client.
Certificate of Authenticity ("COA") is an ID3v2 standard tag type "XCA" or "XCOA" (depending on ID3v2 version) containing an XML file. The XML file has fields that allow identification of the file and licensee of that file. The COA is generated by the MusicMarc Client and appended to the beginning of the MusicMarc track. A COA is based on the Certificate block and some data inserted by the Client.
CHA refers to the SurferlD protocol in internal documentation. Chaff Database is a hidden database that contains records allowing a chaff decoder in MusicMarc to identify the MusicMarc Track being decoded.
Challenge refers to the first half of a message. A challenge contains a command for the peer processor.
Client ID (internally referred to as a VC Serial Number) is an arbitrary value that defines the Client to the Server and vice versa. A Client ID cannot be used by itself to determine anything about the customer, but can be used as a database key if a customer database exists independently. A Client ID is only valid if a CHA transaction occurs immediately after presentation of the ID and that transaction completes successfully. There is no mathematical relationship between shared secret values and the Client ID.
Client refers to the program executing on a customer (q.v.) computer that interfaces with either a SurferlD or a MusicMarc Server. Also referred to internally as Verification Client.
Cookies are persistent data blocks written to a Client or the computer upon which a Client resides for the purposes of tracking. They are used in SurferlD and MusicMarc to bind a specific web browser to a Client.
Customer refers to the human user of the Client program, who is licensed to use the program to access data that is otherwise guarded by SurferlD or MusicMarc.
Download Queue is one or more paid queues. Once a track is in a download queue it may be downloaded by the customer at any time. A track is removed from the download queue once the individual queue itself is deleted.
File Definition Record (FDR) is the record that defines the file that is to be transferred, including its filename and attributes, as well as size. The FDR also includes the header size, and the trailer size, and the total file size. The FDR packet is also used to calculate the frame transfer order. The frame count and frame size is inferred from the packets transferred after the trailer packet. Each frame packet must be the same size.
Frame Group is a number of MP3 frames grouped into a single block that is chaffed as a unit. Frame Transfer Order is the order that frames are transferred in. This order is set by RNG iterations from the FDR packet.
Frames are fixed portions of a file being transferred, sent out of order.
Guarding refers to the process of preventing a customer or other agent from obtaining his shared secret values, or any other protected data as appropriate. This process may include operating system hooks, anti-debugging code, obfuscation, encryption, and/or hardware protection. The data/code to be guarded is only accessed/executed upon presentation of a proper System ID. The Server is guarded by the SurferlD system. A MusicMarc track is guarded by the System ID and an appropriate MusicMarc Client installation.
Header is the first part of the transferred file. It is sent following the FDR and copied verbatim to the beginning of the file buffer.
HTML or Hypertext Markup Language refers to the HTML 3.2 Standard definition or higher, without DHTML or scripting requirements.
HTTP(S) or Hypertext Transfer Protocol / Secure Hypertext Transfer Protocol are protocols defined as international standards. HTTPS refers specifically to HTTP 1.0 or higher using SSL 2.0 or higher.
IIS refers to Microsoft Internet Information Server version 2.0 or higher, used in the release version of SurferlD.
Internal Web Site or Private Web Site refers to the Web site that is guarded (q.v.) by SurferlD.
ISAPI (Internet Server Application Programming Interface) refers to a specification supported in many Web servers, including Microsoft IIS. ISAPI was developed by Microsoft and copied by other competing Web servers. The release version of SurferlD uses ISAPI to interface with the Web server with which it integrates. K value is a pointer number that is used in the Mersenne Twister tt800 or ttl9937 algorithm. SurferlD uses this number and it is thus stored in the shared secret.
Login refers to the presentation of credentials to a peer.
Message is a specific data structure passed in a stream that contains a challenge command, parameters, a response, and an optional payload. A list of messages for each form of stream appears as part of the algorithm documentation. A message may also be referred to as an XCHG. A message that contains a payload is referred to internally as a XCHGEX.
MusicMarc Track is a track that includes a Certificate of Authenticity and is entered into a chaff database.
Peer refers to either the Client or the Server, in the context of the Server or Client respectively.
Ping refers to a single message transaction between peers. HTTP Pings are message transactions that use a Web browser. Ping does not refer to the ICMP PING packet type.
POST Block refers to a HTTP response that was sent by the Client and corresponds to the HTTP POST command specifications.
Processor refers to a finite state machine or other similar virtual computing device that accepts fixed inputs and produces a fixed output based on the state of the machine and its inputs.
Public Site or External Site or Internal Public Site refers to the Web site that is not guarded (q.v.) by SurferlD and may exist within or outside of the SurferlD network domain.
Queue is a track in the progress of transmission. A queue consists of the FDR, header, trailer, and reordered frames. Random Number Generator (RNG) refers to an implementation of the Mersenne Twister algorithm or an iteration thereof. All random number generators used in MusicMarc and SurferlD are Mersenne Twister derivatives. Response refers to the second half of a message. A response contains the calculated value the was output from the local processor based on the previously received challenge.
Server ED is an arbitrary value that identifies the Server. It serves the same function as the Client ID.
Server refers to a program that supplies services to a client over a network connection.
Service Control Manager refers to the Windows NT Service Control Manager, which is defined in the Windows NT API documentation.
Service refers to a Microsoft Windows NT Service application or a UNIX daemon. The implementation of SurferlD Server is currently limited to Windows NT.
Shared Secret is a collection of values that uniquely identifies a user and is found on both the Client and Server. It is guarded by the System ID and consists of the chaff database (in MusicMarc implementations) and the x and k values for the SurferlD authentication system.
Stream or socket refers to a network connection, either a TCP/IP network connection or a named pipe. A persistent stream is backed by mass storage in the form of a file or memory mapped file.
System ID is a general term referring to a unique value that substantially fits the following criteria:
• It is dependent on the Client.
• It is globally unique within the namespace of SurferlD Clients. • It is of the length and character set specified by the Client implementation.
• It is unique to the customer.
• It must be identical each time it is obtained. • A System ID can be a password, a set of computer metrics, a smart card, a biometric reading, or a network ID, or any combination of the above. Both SurferlD and MusicMarc require a 16-byte checksum with no character set restrictions.
Track refers to a bit stream in MPEG-1 Layer 3 format, recorded into a file.
Trailer is the end of the transferred file. It is sent right after the header. It is written following a reserved space for the frames.
Vci refers to the non-portable components of the SurferlD Client. A VCI module is responsible for interfacing with the operating system, network and file system as well as all security aspects. Vcp refers to the portable component of the SurferlD Client. The VCP is a shared implementation and handles the actual algorithm of SurferlD.
X values are an array of numbers that is used in the RNGs on both Client and Server to create unique random sequences that identify the peers to each other.
In the context of the present invention a "Protocol" for allowing intercommunications on a network may be selected from the list:
ONE-PASS: One-Time Password System
PPP-CHAP PPP: Challenge Handshake Authentication
RTP-MPEG RTP: Payload Format for MPEG1/MPEG2 FTPSECEXT FTP: Security Extensions
RTP: Payload Format for H.263 Video ST
MHTML: MIME E-mail Encapsulation HMAC-MD5: HMAC-MD5 IP Auth. with Replay Prevention
IMAPV4: Internet Message Access Protocol v4revl
AUTH-SOCKS: Username Authentication for SOCKS V5
NNTP: Network News Transfer Protocol RTP-MPEG RTP: Payload Format for Bundled MPEG
ETFTP: Enhanced Trivial File Transfer Protocol
D?: Authentication using Keyed SHA
ESP3DES: ESP Triple DES Transform
ST2: Stream Protocol Version 2 IRCP: Internet Relay Chat Protocol
TOS-LS: Link Security TOS
SD7T/UFT: Sender-Initiated Unsolicited File Transfer
MSP2: Message Send Protocol 2
IMAP2: Interactive Mail Access Protocol DMF-MAIL: Digest Message Format for Mail
RDP: Reliable Data Protocol
COOKIE-JAR: Authentication Scheme
NETBLT: Bulk Data Transfer Protocol
ERTP: Internet Reliable Transaction Protocol NVP-II: Network Voice Protocol (ISI-memo)
PVP: Packet Video Protocol (ISI-memo)
PKCS-7: PKCS #7 Cryptographic Message Syntax Version 1.5
PKCS-10: PKCS #10 Certification Request Syntax Version 1.5
PKCS-1: PKCS #1 RSA Encryption Version 1.5 SMIME-CERT: S/MIME Version 2 Certificate Handling
SMIME-MSG: S/MIME Version 2 Message Specification
RC2-ENCRP: A Description of the RC2(r) Encryption Algorithm
CAST-128: CAST- 128 Encryption Algorithm RC5: RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
GZIP: GZIP File Format Specification Version 4.3
DEFLATE: DEFLATE Compressed Data Format Specification V. 1.3
ZLD3: ZLIB Compressed Data Format Specification V. 3.3 HTTP-1.0: Hypertext Transfer Protocol ~ HTTP/1.0
NFSV3: NFS Version 3 Protocol Specification
BINHEX: MIME Content Type for BinHex Encoded Files
ADSNA-IP: Advanced SNA/IP: A Simple SNA Transport Protocol
TACACS: Terminal Access Control Protocol MD4: MD4 Message Digest Algorithm
SUN-NFS: Network File System Protocol
GOPHER: The Internet Gopher Protocol
LISTSERV: Listserv Distribute Protocol
PCMAIL: Pcmail Transport Protocol IMAP3: Interactive Mail Access Protocol Version 3
NFILE: A File Access Protocol
SFTP: Simple File Transfer Protocol
POP2: Post Office Protocol, Version 2
RATP: Reliable Asynchronous Transfer Protocol RTELNET: Remote Telnet Service
Public Domain and Patented Algorithms
SurferlD uses the following algorithms, which will be referred to by their names in the rest of the document:
Mersenne Twister is a family of algorithms developed by Makoto Matsumoto and Takuji Nashumura of Keio University, Japan. For details on these algorithms please see the Marsenne Twister site at http://www.math.keio.ac.ip/matumoto/emt.html. SurferlD utilizes the tt800 algorithm. MusicMarc uses the WFC implementation of the Cokus variation of the ttl9937 algorithm. The exact implementation used is CRandomNumberGenerator2(a), and was implemented by Shawn Cokus, Sam Blackburn, and Yehuda Hahn. The code for the precursor version and associated notes is published by the WFC site at http://ourworld.compuserve.com/homepages/Sam_Blackburn/wfc.htm. Mersenne Twister algorithms and any implementation thereof are all public domain.
One Time Pads are commonly used in cryptography. A definition of one time pads exists at http://www.onetimepad.com/otpexplain.html. The One Time Pad algorithm itself is public domain.
XML is a tagged free-form database file format based on SGML. It follows an international standard. For definitions of XML see http://www.w3.org/XML/.
MD5 is a message-digest algorithm developed by R. Rivest in 1992. Full details are defined in RFC 1321.
TCP D? is a defined protocol and a series of international standards. The TCP/IP implementation used in the release version of SurferlD utilizes the Dundas Ultimate TCP/IP Class Library (referred to herein as "Dundas") over the Windows Socket standard library for Microsoft Windows 95/NT/CE.
SurferlD Peer Authentication Algorithm
SurferlD peer authentication relies on two identical processors with unique System ID and x values. One processor executes on the Server, the other on the Client. The two processors exchange messages on a periodic basis and each message may change the shared secret in either a persistent or non-persistent manner. The persistent state of each processor can be fully defined in the shared secret at any time. The non-persistent state is discarded upon receipt of a Clear command or upon initialization. Synchronization is upon message receipt; a processor may not assume receipt of a persistent message until the network confirms such receipt.
SurferlD Peer Authentication Protocol
TT800 uses an array of 100 bytes (known as an x table) and a control value k (4 bytes) to determine which number should be generated next. The array is modified as a result of this generation and the output [result and output are used interchangeably in this description] is used to calculate the next number. The cycle of numbers is such that a stream of values, assuming a constant source array, is repeated only once every 2 times. TT19937 uses an array of 624 DWORDS (known as an x table) and a control value k (4 bytes) to determine which number should be generated next. This forms a state value of 2500 bytes. The array is modified as a result of this generation and the output is used to calculate the next number. The cycle of numbers is such that a stream of values, assuming a constant
19937 source array, is repeated only once every 2 -1 times.
The TT800 algorithm is used as the core pseudo-random number generator in the CHA version 1 protocol. MusicMarc uses TT19937 internally. For the purposes of this document, the number sizeof(x) will refer to 100 in SurferlD implementations and 2500 in MusicMarc implementations. The term "RNG" will refer to TT800 in SurferlD and TT19937 in MusicMarc. [Any randomization algorithm that utilizes a pseudo-random number generator, either solely or in conjunction with other components, may be used.]
In the CHA implementation, there are three x tables and corresponding k values. They are known as the Saved, Workspace, and HTTP tables. • The Saved table is the persistent data that is modified when so requested by the Server.
• The Workspace table is the data that is modified each time by the challenges (The data checksummed for the response is based on this table).
• The HTTP table is used when responding to CX_HTTP requests.
CHA Handshake
At connect, the Server does not send any message. The Client initiates the handshake by supplying a 32-byte value identifying the Client. The value is: # 416 bytes: Server ID
• 16 bytes: Client ID
The Client ID is a unique 16-byte value assigned by the Server. In the case of a Client that supports multiple users, the Client ID must be registered for each user and must be unique to each. The Server responds by sending a challenge. After the Client responds to the challenge, the user is authenticated. The Client issues a challenge concurrently and may only answer to further challenges if the Server responds correctly to the challenge issued by the Client.
Challenge Format A challenge is a request that the Client take the existing array and manipulate it according to the instructions in the challenge.
The fields of a challenge are:
• 2 bytes: Flags
• 2 bytes: Size • 1 byte: Offset (offset must be a value 0-24. Values above that are interpreted as modulo 25. The number 25 is used for performance reasons on MusicMarc as well.) • 1 byte: RndSize
• 2 bytes: Error control checksum
The flags currently defined are:
• CX_CLEAR: Clear the x table back to the stored values. (All x tables referenced refer to the Workspace table.)
• CX_GENRAND: Generate the RndSize number of random numbers.
• CX_SKD?: Generate random numbers and add the data to the end of that buffer.
• CX_PERSIST: Save this X table to the original stored values. • CX_HTTP: Send the response to this packet through HTTP or secondary channel
The tasks performed are:
1. Check if the Client supports CX_HTTP. If not, and the CX_HTTP flag is set in the request, clear the CX_HTTP flag in the request (The return value will reflect that the Client does not support CX_HTTP). The CX__HTTP flag should only be supported if the protocol requires a secondary channel such as HTTP.
2. If the CX_HTTP flag is set, copy the Workspace table into the HTTP table (All transactions in this message do not affect the main stream if this flag is set).
3. If the CX_CLEAR flag is set, copy the Saved table into the Workspace table. 4. If the CX_GENRAND flag is set, call RNG with the Workspace table in a loop, RndSize times, then set RndSize to 0. 5. Allocate a buffer of size (size+(25-offset)+RndSize)*4, initializing this buffer to an implementation-dependent constant value. 6. Fill the buffer from offset (25-offset)+RndSize with Size return values from tt800 on the Workspace table. 7. If the CX_SKIP flag is set, call tt800 with the Workspace table in a loop, RndSize times.
8. Copy the Workspace table over the beginning of the buffer.
9. Calculate the MD5 checksum of the buffer. 10. If the CX_HTTP flag is set, return the checksum via the secondary channel and set the checksum value in the response packet for CHA to an implementation-dependent constant or random value. 11. If the CX_PERSIST flag is set, save the Workspace table to the Saved table. 12. Return the response packet.
Response Format
The response primarily consists of the output of the transformation [in this non-limiting example being a MD5 checksum] calculated from the challenge. [In the rest of this description, the term checksum or hashing may be used as an example of transformation.] Additional fields in the response packet are:
• Return flags: Flags indicating whether CX_HTTP is supported and how.
• IP address: The IP address of the Verification Client. • VC Serial: The serial number of the Verification Client
• Local signature: The MD5 checksum of the packet.
The VC Serial and Local signature fields are not used in the CHA response, but are only initialized for the HTTP response.
Peer Authentication
In peer implementations of this system, each challenge has a response in it as well. The initial Server packet has only a challenge, with the response field left blank.
The actual structure for each transmission consists of the following:
• Challenge
• Response
HTTP Response Format
The response format of a HTTP response is the same as a regular CHA response.
The response is converted to text before it is sent. The algorithm is a very simple one designed to quickly convert values into a safe text value, bearing in mind that a packet 116 bytes long travels at exactly the same speed as one that is only 72 bytes long. The algorithm converts each byte into a 16-bit value using the following bit transformation:
Let x be the original bit representation. unsigned char x,y,z; // x is the original byte (ObABCDEFGH) unsigned short result; y=x; (y=0bABCDEFGH) z=x; (z=ObABCDEFGH) y&=0xf0; // clear the lower nibble of y (y=0bABCD0000) z&=0x0f; // clear the upper nibble of z (Z=0b0000EFGH) y»=3 ; // shift y three bits to the right (y=0b000ABCD0) z«=l; // shift z one bit to the left (z=0b000EFGH0) y |=0x40; // or y by 0x40 (y=0b010ABCD0) z|=0x40; // or z by 0x40 (z=0b010EFGH0) result=y«8; // result=0b010ABCD000000000 result|=z; // result=0b010ABCD0010EFGH0
Both y and z now have a bit pattern of ObOlOxxxxO. The resulting 16-bit value is made by shifting y left eight bits and adding z. The resulting bytes are always valid for an HTTP POST block. The block is preceded by a three-byte identifier value. The three-byte identifier is currently set to the letters ACK, which are all invalid values for the data itself (all three characters have a LSB of 1.) Note: all calculations assume a little-endian processor. In a big-endian representation changes may be made as needed.
Bytes are verified at destination by doing a simple bit check for AND Oxal and XOR 0x40. If either check fails, the packet is invalidated. The packet is sent using the host browser and HTTP(S), by sending a POST request to a specific location, which is implementation dependent. The location may include a GET request as well (e.g. http://surferid.somewhere.com/surferiaVvs_http_target7identifVmgmformati on&more identifyinginformation) as long as the actual request is a POST request and the identifying data is sent in POST. The SurferlD ISAPI filter will re-map the request to the Verification Server ISAPI Extension (which is a separate entity from the SurferlD Server.)
If the protocol is not HTTP(S), the intercepting driver must pass the resulting value according to the rules of that protocol. For example, if the protocol is FTP, the driver may utilize a transaction method using PORT,
GET, and PUT as needed. In all cases the result must get to the ISAPI
Extension or the Gateway Server.
The ISAPI extension sends the response to the SurferlD Server, which validates the response and returns a cookie to the Client. The cookie is unique in each iteration but is not a function of the response. The Cookie holds the Client's IP address such as to identify the Client for all future requests until the next CX_HTTP packet is processed.
Cookie Validity
The cookie is valid only until the next cookie is issued. However, the expiration date of the cookie is set to a predetermined time after the next cookie is to be issued, to allow for network delays or OLE errors. (Both Netscape Navigator and Internet Explorer require that a browser window be open in order to process OLE commands. In the case of Internet Explorer it must be the same browser window as the one receiving the cookies, while in Netscape all browser windows share a common OLE Server.)
Known Attacks
See Figure 10
The cookie tracking approach has one weakness that can be exploited, where the hacker's computer and the user's computer are on a common subnet behind a firewall, and both are perceived by the Verification System as coming from the same HTTP IP address (that of the firewall), and the hacker is intercepting packets sent to and from the Verification Client computer. The attack also assumes that either the SurferlD system is not configured to use SSL or that the SSL security has been compromised in some way.
In this case, if the hacker can intercept all cookies being sent back to the Client computer and redirect them to his own, the hacker will be able to access data belonging to the Client. The Client, however, will not be able to access his data unless the cookies are sent back to the Client following their inclusion in the cookie cache of the hacker. Also, unless the first cookie and all subsequent cookies are treated in this manner, a security violation will be raised.
Note: MusicMarc uses only a subset of the SurferlD functionality to accomplish the goal of protecting MPS files. SurferlD Server
Components
The Server consists of six major components. 1.Verification Server core 2. CHA portable implementation 3.0ut-of-band channel service 4.HTTP Proxy
5. SAM integration
6. Secret database
See Figure 11
11.1 Verification Server core: The core consists of non-portable NT code that "glues" the components together and provides a security framework and implementation. The core consists of the Gateway and Proxy Servers from the SIBLING system, merged into one service. Messages between the Gateway and Proxy have been removed. The only interfaces supported to the outside world are GefPage and FwPingResponse.
11.2 CHA and Encryption: The CHA protocol implementation is portable and requires the core for implementation specific segments. Encryption uses the Finnish copy of the free Crypto++ library (The original Crypto++ library resides on a Canadian server and is not used to avoid legal issues). See the Crypto++ home page for details. (Note that encryption is only used in countries that allow it and only to the extent permitted by the exporting and hosting countries. Encrypted data is never transmitted except in initial setup of a Client. Encryption is entirely optional.) 11.3 OOB Channel Service: The OOB channel service is the module that transfers data from the TCP/IP network to the SurferlD Core Server. 11.4 HTTP Proxy: The HTTP Proxy consists of an interface between the IIS server and the SurferlD Core Server. Note that the HTTP Proxy server is part of the core. Additional proxies for other protocols can be added, but no formal add-in system is proposed for version 1.0. 11.5 SAM Integration: The SAM user database is used to authenticate users. The service account is used to access per-user data in the secret database, and authentication information is passed as HTTP authentication headers to the host web server. The SAM database is used to initialize user accounts and to verify passwords. 11.6 Secret database: The secret database holds Client and Server x/k combinations for the Client and Server state machines on a per-user basis. CHA uses this information to generate appropriate challenge/response pair messages. 11.7: Verification Client Setup System: Consists of three modules: 1) The Verification Client Generator, which runs on the Server and is responsible for creation and distribution of the Verification Client, 2) 11.8 Verification Client Setup Control Program, which copies support files on the client side prior to execution of the actual Setup executable, and 3) The Verification Client Creator, which creates the Verification Client shared secrets file and actually performs installation.
11.9: Resources: Consists of 1) The Verification Client Loader, the user executable VC.EXE which also supplies the user-interface elements for the Verification Client, 2) The Verification Client Core .DLL, and 3) The Unique data, which are the k and x values supplied to the genrand() function in the Verification Client. Implementation
The SurferlD Server performs three main categories of functions:
1. Verification Server: Verifies Client ping responses against the database.
Connection to the Client is over a dedicated port. If the HTTP integration option is enabled, the Verification Client will also send responses over the HTTP channel. These will be directed to the SurferlD Server via an ISAPI extension.
2. Proxy Server: Proxies HTTP requests from a local copy of IIS to the internal web site. Connection to IIS is over a secured named pipe. 3. Administration Server: Handles administration of on-line users. Connection to the administrative interface is through a local socket.
The Surferlsapi Filter intercepts all HTTP requests and redirects them to the
SurferlD Server which will proxy them to the real site.
An optional HTTP Login extension .DLL is available to allow the user to enter his name and password in an HTML form. This option can be enabled per user. There are three login options: automatic, manual and administrator.
If a user is set to automatic login, his username and password will be passed to the internal site directly from the local database as authentication headers.
This will be transparent to the user, and the user will be authenticated by Verification Client alone. If set to manual or administrator, the user will have to complete a login form to gain access to the site. In the case of manual login, the username and password filled out in the form will be sent on to the site and no username or password is stored in the database. In the case of administrator login, if the user chooses not to complete the HTML form, the username and password found in the database will be sent on to the site. In all cases, the username and password will be sent to the internal site as HTTP Authentication headers. Protocol
The Verification Client sends its login information to the SurferlD Server. If verified, the Client and Server will continue to exchange challenges and responses using the proprietary CHA challenge response system. The Client responds to Server challenges and the Server responds to Client challenges. The Client will be in an authenticated state either until he performs a logout or there is a mismatched challenge/response. In the case of a mismatched Server response, the Client will log himself out. While a user is in an authenticated state, all requests he makes of the web server will be redirected to the internal private site. When an unauthenticated Client makes a request, he will be redirected to the internal public site. The filter checks each incoming HTTP request (IP Address and COOKIE) with the SurferlD Server to see if it is originating from an authenticated user. The SurferlD Server sends all authenticated requests on to the internal private site along with the username and password as HTTP Authentication headers. All unauthenticated requests are send to the internal public site. The response is sent down to the filter, which passes it on to the Client's browser.
Threads
SurferlD Server is a multithreaded application. When the service starts up, it waits to receive notification that all required threads are running, and then reports to the Service Control Manager as started. The threads are all started by the Init function of Proxylnterface, and Init waits on the handle of MainPipeThread before proceeding to shut down. The following threads run in the context of the service: • MainPipeThread: This is the main means of communication between the surferisapi filter and the SurferlD Server. It defines a limited message protocol, which only allows the filter to call certain functions. The other end of the pipe is opened up by the Proxylnterface constructor defined by prxint.cpp, and all communication on the filter end is handled by Proxylnterface functions defined in that file. When the MainPipeThread returns, it is a signal to the Init function that it can begin shutdown.
• AdminPipeControlIer: This thread uses the Dundas server class. It waits for connections from the administrative interface, shuts down when the server event is set upon the MainPipeThread' s shutdown. The administrative interface also has a limited message protocol, which can be sent over a local socket connection on a dedicated port.
• CAdminThread::OnConnect: The CAdminThread class is derived from the Dundas server class. It receives messages from the administrative interface, calls the corresponding Proxylnterface function, and sends the result back to the administrator. Only one connection is allowed at a time.
• AnonPipeReader: This thread receives a page request from the filter, and returns the response from the actual site to the filter. Multiple instances of the thread run, and upon starting each thread checks that there is always one available thread and if not starts one, as long as the total number of threads does not exceed the maximum number of connections as defined in the registry (See section on registry settings).
• TimeoutThread: This thread cycles through all current user sessions and sets to US_VCTIMEOUT those Clients who have not sent a response within the timeout (which is defined per Client).
• Start VS: This thread is the main verification server thread. It is also uses the Dundas server class and it waits for connections from Verification Clients, each of which starts up its own instance of an "OnConnect" thread. CVSThread::OnConnect: is derived from the Dundas server class. When a Verification Client connects to the Server, SurferlD Server starts up an instance of this thread for it, which communicates between Verification Client and Server. It calls the Proxylnterface ::VCLogin and Proxylnterface: :SendPingResponse with the data it reads from the Client, and it sends the results of these functions back to the Client. It recognizes when the Client has logged out when a socket failure occurs and calls Proxylnterface: :VcLogout. If there is a failure in SendPingResponse, it will also perform a logout and notify the Client. VCHTTPPipeController: This is the controlling function for the HTTP Ping infrastructure. SurferlD Server introduces the concept of HTTP Pings as an additional way to authenticate Clients. For Clients running from behind a proxy server, these pings are the only way to identify them. Verification Clients are identified by the IP address from which their pings originate. When they later make an HTTP request of the SurferlD Server, their IP address is checked against the list of running Verification Clients. For Clients running behind a proxy server, the IP address attached to the HTTP request is that of the proxy server and cannot be linked to that of the Verification Client through an ordinary check. The HTTP Ping technology handles this problem. In addition to sending pings through the ordinary channel, the Server occasionally sends an HTTP Challenge. This requires the Client to send its response via a POST request to the verification ISAPI extension .DLL. The verification .DLL, in broad terms, simply reads in the response as a text string, sends it to the SurferlD Server via a named pipe, and receives a cookie in response, which it sets into the Client browser. This cookie is used by the surferisapi filter in all future HTTP requests from that Client in order to identify it.
The VCHTTPPipeController makes sure there is at least one VCHTTPPipeThread available to connect to the verification .DLL. First it starts the VCHttpPipeStarter thread, which waits on an event and creates a new pipe thread each time the event is signaled. Then it loops and checks the number of pipe threads to make sure it is not 0 or negative, due to unexpected thread failures. If it finds no running pipe threads, it creates one. Each VCHTTPPipeThread, upon starting, checks to see if it is the last available pipe and, if so, will set the event for VCHttpPipeStarter to begin a new thread. Upon finishing verifying the HTTP challenge/response, the pipe thread checks to see if there is an available thread. If there is, it will exit. If there is not, it will continue to loop and wait for a connection from another instance of the verification .DLL.
. VCHTTPPipeStarter: This thread is started by VCHTTPPipeController. It waits on the MakeVCPipe event, and creates a new VCHTTPPipeThread each time the event is set.
• VCHTTPPipeThread: This thread waits for a connection from the verification .DLL and upon reading the response to an Http challenge, it verifies it and returns a cookie to the .DLL. Before connecting, the thread checks if there is another available thread. If not, it sets the MakeVCPipeEvent that the VCHttpPipeStarter is waiting on. At the end of this process, it checks to see how many available VCHTTPPipeThreads there are. If it is the only available one, it loops back to wait for another connection; if not, it exits.
• LoginPipeThread: This thread opens a pipe and waits for connections from the login extension .DLL, which is called for Verification Clients who are required to fill out an HTTP login form (where logintype is not set to LOGIN_AUTOMATIC). It receives the post block from the login form, and calls Proxylnterface ::HttpLogin to process it. It returns a pass or fail response to the extension, which will then set the user's state in the filter to US_RETRY_PWD or US_rNVALIDATED_LOGIN accordingly.
Registry Settings
SurferlD is installed as a service in the local services database. All registry settings are under the parameters key in
HKEY_LOCAL_MACHrNE\SYSTEM\CurrentControlSet\Services\SurferI D. They should only be set and changed through the administrative interface. Both the SurferlD Server and the Surferisapi Filter use settings in the registry read at startup; therefore, changes to parameters won't affect the Server until it is restarted.
The following settings are found directly under the parameters key: . AuthEnabled (REG_DWORD): Tells whether the internal private site is equipped to handle authentication headers or not. 0 disables sending of authentication headers, 1 enables it.
• maxpipes (REG_DWORD): Defines the maximum number of users allowed concurrently • vcpinglag (REG_DWORD): Defines the number of seconds the verification server waits between sending out challenges
• vshttplag (REG_DWORD): Defines the number of seconds the verification server waits between sending out http challenges
The following settings are found under the Parameters\ip key: • private (REG_SZ): The IP address of the internal private site (entered as four numbers separated by periods)
• public (REGJSZ): The IP address of the internal public site (entered as four numbers separated by periods) The following keys are found under the Parameters\urls key. Each subkey contains two values, URL and filename, which represents the URL and the physical file it is mapped to of significant local URLs.
• Loginpage: the HTML form which is filled out when the Http Login extension .DLL is enabled
• Loginpost: The Http Login extension .DLL to which the loginpage POSTs.
• Loginretry: The HTML form page to which the user is redirected if his original form submittal fails • Vcpost: the verification .DLL to which the Verification Client posts its response to an HTTP challenge
• Vctimeout: the error page that the user receives if he is not allowed into the private site because of a timeout error.
The Verification Client generator key contains values described fully in the Verification Client documentation.
Data Structures
• VIRTPD7E: Encapsulates the overlapped part of overlapped i o calls on pipes. It contains a pipe handle and a pointer to the overlapped structure, so that reads and writes on pipes will internally perform the overlapped functions.
• VSCOOKIE: This structure is just a text string the length of the cookie set by the verification .DLL.
• LOGINTYPE: This is an enumerated type with three possible values: LOGIN_AUTOMATIC, LOGIN_MANUAL, or LOGIN_ADMINISTRATOR. See above documentation for explanation of these choices. . VCData: The structure that stores all information relevant to the user's Verification Client. • vcview3: Class derived from CRecordSet which is used during VCLogin to get user information from the database looked up by his VC Serial.
• cvcseria!2: Class derived from CRecordSet used during VCLogout and ChaPersist to save user's persistent changed Verification Client data to the database.
• CRSPARAMS: Stores all information relevant to the Verification Client's challenges and responses.
. CRSRESPONSE: The structure that holds the response to a challenge. . CRSXMITHDR: The structure that holds a challenge. • XCHG: A structure made up of a CRSRESPONSE and a CRSXMITHDR that is "exchanged" between Client and Server. Each one verifies the contents of the response, responds to the challenge, and sends a new challenge back in the structure. . CRSHTTPRESPONSE: The structure that holds the response to an HTTP challenge. Because this response doesn't affect bandwidth as much as the ordinary, more frequent responses, it contains a few more user details. . CRSCOOKIE: The binary version of VSCOOKTE that is set into the user's page after the user posts an Http Response to the Server. A valid cookie will uniquely identify the user as an authenticated user.
CHA Technology
The cha challenge response technology is a complex protocol for creating challenges, processing responses to challenges, and verifying those responses. The challenge/response seed numbers are dynamic and the changes are persistent from login to login. The three main functions are:
• CreateChaRequest: Verifies a response and then creates a new challenge.
• ProcessChaRequest: Creates a response to a challenge. • ChaPersist: Saves the Client's dynamic information so that it will persist to the next login.
There is another set of functions that are called from ProcessChaRequest from the Client end in order to send the processed response to an HTTP challenge through HTTP. These functions are described in the Client documentation.
Both the Client and the Server have structures, CRSPARAMS, which contain the dynamic random numbers and the capabilities of the Client (i.e. is it capable of sending HTTP responses? If not, no HTTP challenges will be sent.) These structures are initialized at VCLogin with the information taken out of the database. On the Server end, the CRSPARAMS structures for the Client and Server are stored in the VCData member of the Client's SessionID structure. In addition, the Client and Server each maintain a variable which holds the last challenge they sent out, so that they can verify the response that is returned to them.
The CRSPARAMS structure contains three buffers, which store the random numbers used to generate responses:
• Chabuf: Holds the values that will persist in the database.
• Chawks: Holds the values that are currently being used to generate responses.
• Chahttp: Acts on the Client's side as a scratch buffer to generate HTTP responses, which do not change the chawks buffer, but do use the values currently in the chawks buffer. On the Server side, chahttp holds the values that were present in chawks at the time it sent out the HTTP challenge, so that it can verify the response against those values when it receives the response, which could be much later. Chawks and chahttp have corresponding "k" values.
The challenge which is sent out, a CRSXMITHDR, has the following member variables: • Flags.
Possible values (all flags may be combined):
■ CX_CLEAR: Means that before generating the response, the Client should set the values in his chawks buffer to those in his chabuf buffer, and reset his wksk to 0.
CX_GENRAND and CX_SKIP: Are used internally in the CHA algorithm to control the iterations of the RNG loop.
CX_PERSIST: Means that the values in chawks after processing this response should be saved back to chabuf and then to the database (or VCD file on the Client's end) so that the changes will persist to the next login.
■ CXJHTTP: Means that the response to this challenge should be sent via a post to verification .DLL, in addition to being sent through the ordinary channel. • Size
• RndSize . Offset
• Garbage: A checksum of the challenge.
The response to the challenge is a md5 checksum of the buffer, which should be the same on the Client and Server's end. The following flags can be set in the deRetFlags member of the CRSRESPONSE: . VCR_HTTPRESP: This response is being sent through a POST to verification .DLL and it should be verified against the values stored in the chahttp buffer. • VCRJEΪTTPREQ: The next challenge sent out should be an HTTP challenge. This flag is set by the Server after it has received and finished processing the response to the last HTTP challenge and the lag time between HTTP challenges has already elapsed. VCR_PASSTHROUGH: When the Server receives a response to an HTTP challenge through the ordinary channel, that response should not change the chawks buffer or the corresponding "k" value, because on the Client's end, all processing of HTTP challenges is in a temporary buffer. It should not change the values in the chahttp buffer either, because those must be saved until a response is received through the HTTP channel. Therefore, when the Server receives a response with the VCR_HTTPRESP flag set through the ordinary channel, it sets that flag to FALSE and instead sets the VCR_PASSTHROUGH flag so that the processing of this response should not affect any of the actual buffers.
When the Client first connects to the Server it sends its unique VCSerial number. The Server then uses the GetClientAddress function, fills in a VCData structure with VCSerial and IP address, and calls Proxylnterface:: VCLogin. It returns the response to the Client, which disconnects if the response indicates a failure. The Client then sends in a DWORD, which contains the flags representing its capabilities. The Server calls Proxylnterface: :SendPingResponse with the XCHG structure containing an empty challenge, and the response containing only a deRetFlags member which uses the flags VCR_NOHTTP, VCRJUA E and VCR_UA_NETSCAPE to let the Server know its capabilities. The Server converts those flags to the corresponding VCC_* flags and sets them in the Client's CRSPARAMS structure.
Once inside the SendPingResponse function, the Server checks if this is the first time it is being called (if the pointer which points to the last challenge sent out is NULL). If so, it will use the response structure flag to set the capabilities of the Client. SendPingResponse' s next step is to check whether the Client is ready to receive an HTTP challenge. It checks whether the Client is capable of HTTP responses, then whether the response to the last HTTP challenge was received (which is notified by setting the VSHTTPready flag inside the Client's SessionID structure to TRUE), and last, whether the time lag between HTTP pings has elapsed. If all these are true, it sets the flag in the response structure to VCR_HTTPREQ. If not, it sets VCR_HTTPREQ to FALSE. The Server then calls CreateChaRequest, passing it a pointer to a CRSXMITHDR variable to hold the new challenge created, a CRSPARAMS reference which contains the Client's dynamic seed numbers and its capabilities, a CRSRESPONSE reference which contains its response to the last challenge to verify, and a pointer to a CRSXMITHDR which contains the last challenge to verify. Inside CreateChaRequest, the Server first checks if the last challenge is NULL. If there was a last challenge to verify, it then checks whether it is an HTTP response, or a response through the ordinary channel. It then takes a fresh CRSRESPONSE structure, and sets the flags in it to match the flags set in the response of the Client, and it calls ProcessChaRequest with the last challenge, the fresh response variable, and the Client's CRSPARAMS. This function is used by the Client to generate the response, so if the dynamic information inside CRSPARAMS matches on the Client and Server side (as it should with a valid Client during a valid session), ProcessChaRequest should return a response identical to the one sent in by the Client. After ProcessChaRequest returns, the generated response is compared to the response sent in by the Client. If they don't match, CreateChaRequest returns zero, for failure. If they do match, CreateChaRequest generates a new challenge for the Client. If VCR_HTTPREQ is set in the response, CX_HTTP will be set to TRUE in the new challenge. If the last Client challenge had CX_PERSIST set, the next one will have CX_PERSIST set to FALSE (See next section on persistent challenges). If it is an HTTP challenge, CreateChaRequest will store the current state of chawks and wksk in the chahttp buffer and httpk, and it will save this challenge in the httplast variable. Then CreateChaRequest returns.
The Server checks the result of CreateChaRequest, and returns 0 if it failed. Then SendPingResponse checks if the Client sent it a challenge in the XCHG structure. If so, it calls ProcessChaRequest to generate the response to that challenge. It then copies the new challenge it created in CreateChaRequest into the challenge part of the XCHG structure, and its own response to the Client's challenge into the response part of the XCHG structure. The Server checks the last challenge that it just verified to see if CX_PERSIST was set to TRUE. If TRUE, that means the Client saved its dynamic information after sending its response to the Server to be verified. If CX_PERSIST was set to TRUE, after a successful call to CreateChaRequest, the Server will call ChaPersist to save the Client's dynamic information to the database. After persisting, the Server overwrites the "last" variable, which holds the last challenge sent out in order to verify it. (If the response was sent through the HTTP channel, it does not actually send the Client the challenge created during the call to CreateChaRequest. That call is just to verify the response. Therefore, it doesn't copy the challenge if deRetFlags in CRSRESPONSE is set to VCR_HTTPRESP.) Finally, SendPingResponse returns to CVSThread::OnConnect (or FwHttpPingResponse in the case of an HTTP response) with its result. The Server sends out the XCHG packet with the new challenge and the response to the Client challenge. If the send function returns successfully, the Server will then check if the last challenge it responded to had CX_PERSIST set to TRUE, and if so it will call CommitChaBuffers, which calls ChaPersist to persist the Server's dynamic information to the database. The Server sits in a loop reading an XCHG packet from the Client, calling SendPingResponse, sending out a new XCHG packet, persisting Server information if necessary, and then returning to the beginning of the loop. If at any point a socket call fails (other than a timeout error) or the SendPingResponse fails, the Server performs a VCLogout and the thread exits. The ChaPersist function is always called after the response was generated and the send of the XCHG packet to the other side was successful. On the side that verifies the challenge, ChaPersist is called after the challenge is verified. This is done to ensure that the dynamic information that is persisted is synchronized on both sides and is the same. Thus, if the socket is cut off and the Client loses connection to the Server before the persistent challenge was returned, neither will have saved the dynamic information, but if it is after the persistent challenge was successfully returned, both will have saved it. Furthermore, two persistent challenges are not sent in a row. There are two flags inside CRSPARAMS that change the behavior of ProcessChaRequest and ChaPersist. The "server" flag tells ChaPersist whether the CRSPARAMS structure is that of the Server or that of the Client, so it will know where in the database or vcd file to save the information. The verify flag tells ProcessCha request whether it is being called from CreateChaRequest to verify the response to a challenge, or whether it is being called directly to respond to a challenge. This makes a difference when it comes to HTTP challenges, which utilize different buffers during creation from those used during verification.
SurferlD Client Implementation
The Client is a self-installing transparent plug-in that authenticates access to a SurferlD Server.
The Client setup has the following design goals: • Each Client is unique.
• A customer authenticates himself to the setup application using a password combination received from the Server. The passwords are used to decrypt the setup package (where allowed); it is assumed that the Server administration will only give the passwords if the customer identifies himself adequately.
• The setup application itself is generally sent either through e-mail, HTTP direct download, or media distribution.
• The setup system automatically registers the Client with the Server.
• The setup system automatically integrates the Client with web browsers. The Setup application consists of three programs:
1. Verification Client Generator: This module runs on the Server and is responsible for creation and distribution of the Verification Client. 2. Verification Client Setup Control Program: This module copies support files on the client side prior to execution of the actual Setup executable.
3. Verification Client Creator: This module creates the Verification Client shared secrets file and actually performs installation.
Verification Chent Generator
The SurferlD Verification Client Generator project consists of the following sections and modules: 1. Initial Passwords 2.VC Serial 3. Utilities
4. Create VerificationClient
5. CreatelnstallExe
6. Create Vclnstall 7. EncryptThelmage
Initial Passwords
The Initial Passwords module interfaces with an ODBC data source. It consists of a standard derivation of CRecordset and exposes the following interface methods and variables: class InitialPasswords : public CRecordset
{ long m_userid; long m_pkid; int m_fileno; C String m_initpwdl ;
CString m_initpwd2;
};
This interface is used in the workflow to determine the initial encryption key for the Verification Client. PKID and user ID are used to query the interface. The user ID and the PKID are determined by the input to the main entry point.
The DSN used to log in is defined as "SurferlD." Access must be anonymous or encapsulated in the DSN open string and hard-coded into the class definition. Furthermore, the DSN must be a system DSN, as it is accessed by services as well.
VC Serial
The VC Serial module interfaces with an ODBC data source. It consists of a standard derivation of CRecordset and exposes the following interface methods and variables: class C VCSerial : public CRecordset
{
CByteArray m_serverx; long m_timeout; long mjjserid;
CString m_vcserial;
CByteArray m_x; long m_pkid;
}; This interface is used in the workflow to update the serial number and x variables for the Server and Client on the newly generated Verification Client. The VC Serial database is updated by the generator. If no entry exists for the PKID and user ID specified, a new record is added. The timeout is not updated by the generator and must be maintained by a separate tool on the server.
The DSN used to log in is defined as "SurferlD." Access must be anonymous or hard-coded into the class. The user ID and the PKID are determined by the input to the main entry point.
Utility Library The utility library contains all of the miscellaneous functions used by the generator. These functions may be reused in other contexts as well.
Function List
CString GenVCText(unsigned long * a=NULL);
GenVCText creates a new VC serial number, of the format VCaaaabbbbccccdddd, where a, b, c, and d are 32-bit integers, rendered in hex.
Parameters:
(unsigned long ) optional parameter: A pointer to a 4-DWORD buffer that receives the serial number. Return value:
(CString): A string representation of the serial number. DWORD StringToAddress(LPCSTR lpstr);
StringToAddress converts a string IP address (dotted form) into a compressed DWORD in local byte order. The return value is used in internal messaging but cannot be passed to socket functions that require network byte order. The winsock byte ordering functions can be used to convert this IP address into network byte order if desired.
Parameters:
(LPCSTR): A string representation of the IP address.
Return value: (DWORD) : The IP address.
void RealToDisplayed(BYTE * tribyte,BYTE * fa); void DisplayedToReal(BYTE * fa,BYTE * tribyte);
These functions convert strings that contain unprintable characters to printable characters only using this algorithm: Three real bytes are divided into four bytes as thus:
Original three bytes: x234 5678 9abc defg hijk lmno
Transformation:
0x12 3456 0718 9abc Odle fghi Oj lk lmno In this manner, all bytes are forced to be greater than 32 and less than 128. (0 and 1 are literal.)
Bits 6 and 8 are both ignored in the reconstruction.
Parameters:
(BYTE *) tribyte: The three-byte representation (real). (BYTE *) fa: The four-byte representation (displayed).
In each case the output buffer must be four bytes long.
void shavetop(BYTE * in,BYTE * out); void minoxidil(BYTE * in, BYTE * out);
Converts 7-bit to 8-bit and back. The shavetop and minoxidil algorithms complement each other.
Shavetop Algorithm: Given 8 bytes:
0123 4567 089a bcde Ofgh ijkl Omno pqrs
Otuv wxyz OABC DEFG OHIJ KLMN OOPQ RSTU
Reduce to 7 as: 1234 5678 9abc defg hijk lmno pqrs tuvw xyzA BCDE FGHI JKLM NOPQ RSTU
0 is literal.
Minoxidil Algorithm
Given 7 bytes: 1234 5678 9abc defg hijk lmno pqrs tuvw xyzA BCDE FGFfl JKLM NOPQ RSTU
Expand to 8:
0123 4567 089a bcde Ofgh ijkl Omno pqrs
Otuv wxyz OABC DEFG OHIJ KLMN OOPQ RSTU 0 is literal. Parameters:
(BYTE *) in: The input buffer (either seven or eight bytes).
(BYTE *) out: The output buffer (either eight or seven bytes).
BYTE * GenerateKeys(int pkID); This function creates the initial encryption key based on the PKID supplied. The initial key is drawn from the Initial Passwords module. The keys (initialPasswordl and initialPassword2) are run through the shavetop algorithm. The resulting binary string forms the return value.
Parameters: (int) PKID: From which the key is derived.
Return value:
(BYTE *): Binary key string.
The return value is dynamically allocated using malloc() and must be freeQd. Create VerificationClient
This is the main entry point into the application. This function forms the main workflow for the generator. Create VerificationClient does the following: 1. Generates user keys (using GenerateUserKeys).
2. Determines the source locations for the components of the Client (See the External Dependencies, CreatelnstallExe and CreateVcInstall sections for details).
3. Initializes the Verification Client Header. 4. Assigns a VC Serial number (using GenVCText).
5. Creates the in-memory layout of the VCD file.
6. Calls CreateVcInstall to create a Verification Client core/unique resource and the associated setup package.
7. Saves the Header x variables and serial number to the CVCSerial database.
Create VerificationClient has an exception handler for CException * based exceptions only.
The Create VerificationClient module has one function:
int CreateVerificationClient(HWND hStatus, int uid, int pkid, LPSTR IpTarget); Parameters:
(HWND) hStatus: Window handle to receive status report, (int) uid: The user ID. (int) pkid: The PKID. (LPSTR) IpTarget: The final executable setup program file name. Return value:
(int) nonzero on error. External Dependencies:
ODBC DSN: The DSN must be anonymous and named SurferlD. Registry key:
HKEY_LOCAL_MACHTNE\System\CurrentControlSet\Services\SurferI D\
Parameters\ Verification Client Generator". Values: VCLoader: (REG_SZ) the location of the VCLoader.
VCDLL: (REG_SZ): The location of the VC DLL source (vcdllx).
VCSetup: (REG_SZ): The location of the Create VC program.
IE driver: (REG_SZ): The package file (including NPVC and the redistributable .DLLs). Ctrl File: (REG_SZ): The VC setup control executable file.
VSrP: (REG_SZ): IP Address of the VS.
VSName: (REG_SZ): Name of the VS. Required Source Headers: vcserial.h (local) initialpasswords.h (local) oxregistryitem.h (Ultimate Toolbox)
CreatelnstallExe
The CreatelnstallExe module has one function:
int CreateInstallExe(COXPathSpec & createvc, COXPathSpec & target); CreatelnstallExe creates a full install package out of the Setup file (with the installation resources in it) and the state variables extracted from the registry by the Create VerificationClient function. Details are described in the section on SetupCtrl.
Resources are allocated in the setup control file and the new copy becomes the setup executable for the client.
Parameters:
(COXPathSpec &): The path to the temporary copy of the setup file.
(COXPathSpec &): The path to the target setup location. Return value: (int) nonzero on error. CreateVcInstall
The CreateVcInstall module has one function:
int CreateVCInstall(LPBYTE lpKey,LPSTR rlpSetupExe,LPBYTE lpVcd,DWORD wVcdSize,CWnd * cEdit); Creates a VC Installation file, aheady encrypted with a 96-byte key. The function receives the randomly generated VC Key and the VCD file, and generates from that and the hard-coded path to the base EXE a compressed file. The encrypted file is stored as a resource in a copy of the VC setup .EXE file. The VC Setup program looks for this file as a resource and decrypts it into its components.
The header of the installation file consists of the following data structures: struct MyCabinetHeader { DWORD dwSignature;
BYTE md5[16]; // must end before offset 0x20 in the file
DWORD dwLoaderSize;
DWORD dwVcdSize;
DWORD dwExeSize; DWORD dwSupportDLLSize; // not currently implemented, must be
0
DWORD dwSupportDLLOffset; // not currently implemented, must be O
}; struct RealCabinefHeader { DWORD dwCabsize; MyCabinetHeader mch;
}; The CreateVcInstall module performs the following steps:
1. Makes a temporary copy of the Create VC setup program.
2. Creates and initializes a copy of the cabinet header as defined. (The
Support DLL fields are not currently used.)
3. Compresses and encrypts the VCD in-memory image using the supplied key. 4. Copies the compressed/encrypted image to a resource in the Create VC setup program copy. The resource is called VC of type VC.
5. Calls CreatelnstallExe to complete the generation.
Parameters: (LPBYTE) IpKey: Encryption key (EncryptThelmage handles the codec).
(LPSTR) rlpSetupExe: The path to the Setup executable.
(LPBYTE) lpVcd: In-memory image of the Verification Client unique image (VCD structure). (DWORD) dwVcdSize: Length of the image.
(CWnd *) cEdit optional: Edit control to update with status. Return value:
Nonzero on error. External Dependencies: "cryptlib.h": Crypto++.
"misch": Cryρto++.
"md5.h": Cryρto++.
"crypfile.h": Ultimate Toolbox.
"oxcmpfl.h": Ultimate Toolbox. "path.h": Ultimate Toolbox.
EncryptThelmage
This is the encryption utility for SurferlD setup. It assumes the following:
1. Encryption algorithm is symmetric.
2. It uses a child algorithm class of BlockTransformation. 3. The key is 96 bytes long. EncryptThelmage can use any reduction algorithm to reduce the key if necessary. Alternatively, key is 16 bytes and is used as is. To determine the actual key length, if bytes 17-96 are NULL, the key is only 16 bytes long.
4. dwSize is a multiple ofBlockSize. Current implementation (6/19/97 version): Uses CAST- 128. The key is a MD5 checksum of the IpKey buffer. Any Block Transformation algorithm can be used instead as long as the key size is 16 bytes or less. (Implementations of MusicMarc utilize CryptoAPI or 56-bit symmetric-key encryption algorithms.)
Function List
int CryptoInternal(LPBYTE lpImageIn,LPBYTE lpImageOut,DWORD dwSize, BlockTransformation * ce)
Cryptolnternal is the actual engine. It requires a BlockTransformation derived cipher from the Crypto++ library, but works with any available block cipher.
Parameters: (LPBYTE) lplmageln: The input image to encrypt.
(LPBYTE) lpImageOut: The encrypted output buffer.
(DWORD) dwSize: The size of the buffer (both buffers must be the same size).
(BlockTransformation *): A pointer to a preset cipher. The key must be initialized in the cipher engine before passing it to this function.
Return value:
(int) nonzero on error.
int EncryptTheImage(LPBYTE lpKey,LPBYTE lpImageIn,LPBYTE lpImageOut,DWORD dwSize); int DecryptTheImage(LPBYTE lpKey,LPBYTE lpImageIn,LPBYTE lpImageOut,DWORD dwSize);
These functions are wrappers around Cryptolnternal. They choose the CAST- 128 algorithm and set the key, and then call Cryptolnternal to do the real work. Parameters: as in Cryptolnternal. Return value: as in Cryptolnternal. External Dependencies:
Crypto++ (MD5 and CAST 128 or other algorithm) Verification Client Setup Control File
The SurferlD Verification Client Setup Control file has only one module. It does not use MFC. SetupCtri has two threads, a worker unpacking thread and a user interface thread. The user interface thread is the main thread. It creates a status dialog box, which shows the installation status to the user. The worker thread follows the following steps:
0: Reading archive file
1 : Unpacking setup distribution 3 : Unpacking createvcs (called the Setup Wizard in the user interface)
4: Launching createvcs
5: Cleaning up
Reading Archive File
The archive file containing the redistributable files and the Netscape plug-in file is stored in the resource VCDATAWCCONST of the SetupCtri exe, and is copied there by the VC generator.
The archive file is a Microsoft CAB file. It is not encrypted. It is generated using the createcabs batch file, which compresses the MFC, CRT and other associated files and the NPVC DLL into one CAB referred to internally as vcconst(αVr).
Unpacking Setup Distribution
The archive file is unpacked locally into a temporary directory.
Unpacking and Launching createvcs
The createvcs program is stored in VCDATAWCXTRA. It is unpacked to the temp directory and executed from there.
Cleaning up
The temp directory is then cleaned up. Create Cabs Batch File
This batch set allows development of test Clients. It assumes the following environment variables:
. VCSOURCES: The directory to store the CAB files. • SYSREDIST: The directory containing redistributable files.
• VCUNINST: The directory containing the VC Uninstall program (without debug/release).
. NPVC: The directory containing the VC Plug-in program (without debug/release). • VCG: The directory containing the Verification Client Generator (command line version).
• CAB ARC: The directory containing the cabarc program.
@echo off
%CABARC%\cabarc n %VCSOURCES%\debug.cab %SYSREDIST%\mfc42d.dll %sysredist%\mfcd42d.dll
%sysredist%\mfcn42d.dll %sysredist%\mfco42d.dll
%sysredist%\msvcrtd.dll
%CABARC%\cabarc n %VCSOURCES%\sources\release.cab
%sysredist%\msvcrt.dll copy %VCSOURCES%\debug.cab %VCSOURCES%\redist.cab
%CABARC%\cabarc n %VCSOURCES%\vcconstd.cab
%VC SOURCES%\redist.cab %NPVC%\debug\npvc.dll
%VCUNTNST%\debug\vcuninstall.exe copy %VCSOURCES%\release.cab %VCSOURCES%\redist.cab %CABARC%\cabarc n %VCSOURCES%\vcconstr.cab
%VC SOURCES%\redist.cab %NPVC%\debug\npvc.dll
%VCUNTNST%\debug\vcuninstall.exe
%CABARC%\cabarc n %VCSOURCES%\vcconstx.cab
%NPVC%\debug\npvc.dll %VCUNTNST%\debug\vcuninstall.exe copy %VCSOURCES%\vcconstd.cab %VCSOURCES%\redist.cab rebuild quit O
The rebuild batch file expects three parameters: the PKID of the Client record, the user ID, and the filename to create. In release usage, the SurferlD Administrator automatically invokes the VCG program with all relevant parameters and then transmits the file.
(Secho off pushd cd %VCG% vcg %1 %2 %VCSOURCES%\%3 popd quit 0
Verification Client Creator (Createvcs)
The SurferlD Verification Client Creator program has the following modules:
1. System ID 2. User Interface
3.VC Create Core (vccc)
4. Plug-in Install
5. VCD Generator (vc build)
6. EncryptThelmage (defined above) 7. Shavetop (defined above)
System ED
The System ID framework is described in the section System ID.
User Interface
The user interface consists of an installation wizard. The wizard has three sheets: l.User authentication. This sheet requests the password and authentication code (defined in the server-side database as initialPasswordl and initialPassword2.)
2. Directory selection. This sheet retrieves the directory (default: C:\Program Files\SurferID Client) to install the SurferlD client to.
3. Status. This updates the user as steps of the installation are completed.
VC Create Core (VCCC)
VCCC handles the Verification Client creation and extraction from the resources in the Create VCS executable. Structures struct Signatures {
BYTE md5[MD5::DIGESTSIZE]; // md5 digest of whole unencrypted // file except for the first 16 bytes
DWORD dwSig; // some constant value
DWORD dwExeLength; // compressed exe size!
DWORD dwBigExe; // uncompressed EXE size
DWORD dwVcdLength; // uncompressed vcd size BYTE exeo[MD5::DIGESTSIZE]; // uncompressed exe digest
BYTE vcdo[MD5::DIGESTSIZE]; // vcd digest
}; struct MyCabinetHeader {
DWORD dwSignature; BYTE md5 [16]; // must end before offset 0x20 in the file
DWORD dwLoaderSize;
DWORD dwVcdSize;
DWORD dwExeSize;
// support DLLs (not used in Version 1.0) DWORD dwSupportDLLCount;
DWORD dwSupportDLLOffset;
};
Function List int LoadVcResource(LPBYTE lpPassword,LPB YTE & vccab,int & size); Loads the resource, unencrypted, into memory image.
The file library in a Create VC application is stored in a resource file attached to the executable. The resource is called VC and is of type VC.
Input:
(LPBYTE) lpPassword: The key. Output:
(LPBYTE &): The cabinet file.
(int) FALSE on error.
This function does not verify the validity of the file. It merely expands it and decrypts it. Decryption is done using the DecryptTheFile function.
void MoveFileDelay(LPSTR lpTarget,LPSTR IpSource); This function moves files that are currently open using system-dependent calls. In Windows 95 it adds the files to a registry key that automatically renames them on reboot. In Windows NT it uses the MoveFileEx function. Parameters:
(LPSTR) IpTarget: The target filename.
(LPSTR) IpSource: The source filename.
Errors cannot happen in this function.
int Write VCLoader(LPBYTE lpVccab,LPSTR IpAppPath); Writes the Verification Client Loader into the application path specified. Input:
(LPBYTE) vccabinet: Preverified VC cabinet file. (LPSTR) IpAppPath: Target application path. Output: (int) zero on error.
Throws exceptions on error. Calls external function CreateUsig.
int RegisterDll(LPCSTR lpPath);
Registers a COM DLL. A utility function for shared .DLLs that need registering (Version 1.0 does not currently have any).
Input:
(LPCSTR): Path to the .DLL. This must be the final path for the .DLL.
.Output:
(int) HRESULT: Result of error code. Can be tested using FAILED() and SUCCEEDED^)
LPSTR GetSourceDirectory(void);
A utility function that returns the temp directory from which createvcs was launched.
Output: (LPSTR): The directory path. int DoNsSupport(LPCSTR lpSourcePath,LPCSTR lpTargetPath);
This function installs the Netscape plug-in into the appropriate location. It automatically senses Netscape Communicator, Netscape Navigator, and Internet Explorer and copies the plug-in into the appropriate location. This function invokes the Plug-in Installer module.
Input:
(LPCSTR) lpSourcePath: The path to copy from.
(LPCSTR) lpTargetPath: Ignored at present.
Output: (int) error code.
int DoIeSuρport(LPCSTR lpSourcePath,LPCSTR lpTargetPath);
This function installs the Internet Explorer ActiveX control and copies it to the appropriate location. It is not currently used.
Plug-in Install The plug-in installation module handles the registration and installation of any browser (or other program) drivers for SurferlD Client.
The current installation module handles installation for Microsoft Internet Explorer and Netscape Navigator by copying the npvc.DLL file to the appropriate directories.
VCD Generator (vc build)
This contains the functions needed to create a VCD file. Many of these functions contain code that is also used in the Client Loader, so if something is changed here it needs to be changed there too.
Function List
int Create VCData(MyCabinetHeader * mch);
This function creates a file called VCDATA.VCD in the target directory based on the cabinet header supplied. The file is encrypted using EncryptThelmage and compressed using the COXCompressor, and signed with MD5. This function calls SetVCDPath to set the location of the VCD file in the registry.
Input: (MyCabinetHeader *) mch: The location of the cabinet in-memory image, decrypted.
Output: error code.
5 void SetVCDPath(LPSTR path);
This function sets the path to the VCD file in the registry. The registry path is ro EY_CURRENT_USER\SOFTWARE\SurferIDWerification ClientWCD Location.
Input: o (LPSTR) path: The VCD path to set.
int GetSystemID(BYTE * lpDigest,DWORD & dwErr); See the System ID section for details.
Verification Client Loader
Goal 5 The Verification Client Loader is the user executable VC.EXE. It uses various techniques to make it difficult to determine the actual code of the Verification Client, in order to prevent reverse engineering, and checks for the existence of a System ID. It also supplies the user-interface elements for the Verification Client.
Specifications
The Verification Client Loader has these tasks:
1. Locates and opens the VCD file.
2. Determines the System ID.
3. Reads the VC Core file from the VCD. 4. Reads the VC Unique data from the VCD, if relevant.
5. Initializes user interface components.
6. Writes the VC Core to a temporary file, keeping the file locked with a delete-on-close flag. 7. Dynamically loads the Core, passing the VC Unique data in an implementation-dependent manner. The Core is spawned using flags that prevent a debugger from bridging into it.
8. After the Core returns, the VC Unique data is written back to the VCD, if relevant.
Finding the VCD File
Generally the VCD file will reside in the same directory as the Loader.
System ED
See the System ID section for details.
Core File
See the Core section for details.
Unique Data
The Unique data are the k and x values supplied to the genrandO function in the Verification Client. The current genrand() function uses a 100-byte x value and a 4 byte k value. The Unique data comes with a 72-byte header containing locator and user information, raising the actual size of the Unique data to 176 bytes. The primary rule with a Unique data block is that is must be of a size evenly divisible by 16, and must include the 72-byte header including a 16-byte MD5 checksum. On systems that include a hardware key with memory, a portion or all of the Unique data may be stored on the key itself. In such cases, only the header is saved as Unique data.
The Unique data is stored as part of the Shared Secret.
The Anonymous Memory-Mapped File The Verification Client is a spawned process of the Verification Client loader. The anonymous memory-mapped file allows secure data transfer between the parent and child processes using inherited handles.
Note: If the System ID is stored on an external device such as a hardware key and that key has read/write memory, some or all of the anonymous memory-mapped file may be stored on that key instead of through the anonymous file. The other precautions may still be used to prevent disassembly and patching to remove the dependency on the key.
Initializing User-Interface Components
Because the user interface is OEM-specific, the components may need to be initialized before the VC is actually loaded. The default Verification Client needs no user interface at all and does not display one.
The VC Core Temporary File
Windows will not run executable files unless they are committed to disk first. The VC core is committed to disk just before it is run, but it is locked to prevent disassembly and duplication. The lock handle is set to delete the file on close. (The VC Core is also encrypted/compressed with Shrinker or a similar at execution.)
Dynamically Linking to The Core
The Core is currently a .DLL. The anonymous handle is shared between the .DLL and the executable, allowing separation into processes as needed. The Core can be made into an independent executable and the loader replaced, as the two do not share any essential data except through the anonymous file.
Updating the Unique Data The Unique data is modified on exit from the Verification Client with a new k and x value. This data is encrypted and placed back in the VCD file.
On systems that include hardware keys with memory, this step is skipped.
Verification Client Core
Goal The Verification Client is a client-side module that implements authentication using a separate channel. It does this by relying on a unique System ID which can either be a password, system and user settings, or OEM value. The SDK version of the Verification Client will include the tools needed to replace the System ID generator with a new one. Specifications
The Verification Client is a client-side component and as such must be protected against client tampering or replacement. It does this using the following security precautions: 1. The VC Data is never stored on disk except in encrypted form.
2. The VC executable is stored on disk only for the time it is actually executing, during which time it is exclusively locked. This makes interpretation of the EXE very difficult.
3. The VC Loader stores MD5 checksums to the VC executable and VC data. The checksums are used as part of the password for the EXE, making it very difficult to determine how much of it is static data.
4. The EXE is compressed before it is stored. This removed duplicate spans that might reveal cryptographic data. (Visual C++ leaves lots of empty space in its executables.) 5. The entire file is compressed at execution using Shrinker. We do not rely exclusively on this method because Shrinker is a popular program and someone may know how to break it.
The Core is the actual verification method. The Core does the following steps: • Opening the Unique Data.
2. Retrieving the System ID and comparing it to the one in the Unique Data.
3. Opening a TCP/IP connection to the Verification Server.
4. Handshaking with the Verification Server.
5. Responding to challenges. 6. Closing the connection if it is rejected, terminated, or closed on the other Side.
7. Updating the Unique Data.
8. Opening the Unique Data
The Unique data is passed to the Core in an implementation-specific manner. System ED
The Unique data includes a System ID. The Core periodically checks the System ID against that ID to insure that it has not changed. (This test is suppressed on Clients with fixed IDs that cannot be changed while the program is running, and on those in which the ID is that of an external device which generates the random-number sequence.)
TCP/IP Session to Verification Server
The IP address of the Verification Server is encoded in the header of the Unique data. The target port is a fixed port below 1024 and is hard-coded into the Verification Client. The server and client communicate using a proprietary protocol.
Handshake
The handshake sequence begins with the Verification Client sending its serial number to the Server. The Server verifies that the serial number is in valid format and then sends it to the Proxy Server's Verification Subsystem. The Verification Server then returns a status code indicating if access is permitted to this client at this time, and a challenge to the shared secret.
Sequence Numbers
If the status code was valid, the Client generates a response XCHG. Only after receipt of a valid XCHG will a client be considered "logged in" and then only until the XCHG sent is not valid. An invalid XCHG is used as a signal to terminate the connection on the client side.
Closing the Connection
The client continues sending XCHG with a preset delay until one is rejected. Each XCHG that is accepted is acknowledged with another XCHG. The connection is closed by TCP close connection.
Updating the Unique Data
The Unique data is updated at this point with the new k and x values. On systems verified using a hardware key with memory, the Unique data is updated in the key memory. (The data is not updated if no CX_PERSIST commands were sent.) Browser Integration
As described in the CHA documentation there is a link between the Verification Client and the browser that spawned it. If a CX_HTTP command is sent to the Core, it repeats the response through any browsers that have registered with it. It does this by posting this response to a public virtual memory mapped file (which is open for exclusive write but not read) and triggering an event. While there is a possibility of exploiting this file for all sorts of nefarious purposes, the risk is low as the data is in plain text and can be intercepted via the browsers anyway. It is due to this that the challenges are always sent in the private channel and that most of them are not CX_HTTP challenges.
SurferED Client Loader
The Client Loader consists of two modules: 1. User interface 2.VC Core Loader
User Interface
The user interface is invisible and subject to each OEM implementation.
VC Core Loader
The Loader, contained in the vcslf module, consists primarily of cut-and-paste copies of the System ID modules, EncryptThelmage, and three major functions:
int UnpackVC(LPSTR lpVcdFile,HANDLE * _hMapping,LPSTR
IpExeBuffer)
UnpackVC opens the VCD file and prepares the environment for the actual launch of the Verification Client core. UnpackVC calls GetSystemID for System ID information necessary to decrypt the Verification Client, and then creates two images ~ the core image and the unique image. The unique image is stored in an anonymous memory-mapped file that is shared between the client and the loader. (In future revisions this may be changed to a local memory buffer. The core image is the complete .DLL of the Verification Client, and is written as a temporary file. The .DLL is vulnerable between the calls to UnpackVC and the LoadLibrary call in DoVCReal. Input:
(LPSTR) lpVcdFile: The VCD filename. Output:
(HANDLE *): Ppointer to the handle for the memory mapped unique file. (LPSTR) IpExeFile: The path to the core file, (int) return value:
-1 : verification or corruption failure (System ID does not match).
0: success. anything else: general failure error.
int DoVC(VCLdrWindows * n)
Launches DoVCReal and other associated functions.
DoVCReal
The Verification Client loader core program
1. Locates the VCD file. 2. Unpacks the VCD file using helper functions, (if the VCD was modified, the helpers detect it and fail.)
3. Loads the VCD core.
4. Calls the VCD core entry point.
5. Updates the VCD with the new unique data. 6. Closes everything and cleans up.
Note: DoVCReal does not do anything special for Web browser integration. It is the sole responsibility of the VCD core to handle browsers.
DoVC creates a worker thread for the Verification Client. The Verification Client loader itself sits in the DoVCReal function, which eventually calls the VCEntry entry point in the core.
The VCLdrWindows structure contains pointers to all of the various windows defined in the user interface and used for feedback. The VCLdrWindows structure is defined as: struct VCLdrWindows {
CEdit * servername; // m_serv CEdit * connectionrate; // m status CButton * connect; // m_connect CButton * disconnect; // m_disconnect
};
Please note that VCLdrWindows is completely optional. DoVCReal is an internal thread procedure. DoVCReal opens the VCD file pointed to in the registry, unpacks it (using UnpackVC), loads the core contained therein, finds the VCEntry entry point, and passes control to the VCEntry function. After VCEntry returns, the core is freed and deleted and the mapping is deleted. The VCD is updated using Update VCD.
The core is deleted before calling VCEntry in the release build. The core is compiled with the SWAPRUN:NET option to allow it to be deleted.
Startlelnterface has been phased out.
int Update VCD(LPSTR lpVcdFile,HANDLE hMapping) UpdateVCD writes new x_values into the VCD file from the memory mapped file. It uses the same algorithm as that used in createvcs. See the actual source for details on the update algorithm.
UpdateVCD uses a background thread which is triggered by an event in CxPersist. The event is synchronous and is used instead of a direct call so that thread-local data in the persistence implementation does not affect the actual Client and does not require a specific calling convention, process, context, or location.
Input:
(LPSTR) lpVcdFile: The path to the VCD file. (HANDLE) hMapping: The map handle.
Output:
(int) nonzero on error.
SurferlD Client Core
The core consists of two main sections: the portable core, and the system dependent core. The portable core is documented in the section SurferlD Portable Kernel and contains the vcp module. The interface between the two sides is defined as:
Structures
// vc data file header struct VCHEADER {
DWORD dwSig; // signature field DWORD dwIP; // IP address of the server
DWORD dwSerialno[4]; // VC Serial number DWORD dwKey[4];
DWORD dwSaltLengfh; // hard-coded to 25 char serverName[32]; // server text name }; struct VCD {
VCHEADER vcHeader; DWORD x[25]; // client x variables DWORD serveιx[25]; // server x variables };
Function List
Non-portable functions called from portable code
int VcStartCommunications(LPVOID statedata); Starts the primary comm channel between the Client and the server.
If VcStartCommunications returns nonzero the Verification Client calls VcShutdown and then exits.
int VcSend(LPVOID statedata,LPBYTE data,DWORD dwSize); int VcReceive(LPVOID statedata,LPB YTE data,DWORD dwSize); Implementation independent socket send/receive functions.
int VcGetResponseSettings(LPVOID statedata,DWORD * dwSettings); Sets carrier bits in the CX_HTTP response sections.
int VcGetParamSettings(LPVOID statedata,DWORD * dwSettings); Sets carrier bits in the CX_HTTP part of the CRSPARAMS.
The HTTP module is linked to through the implementation-dependent section, therefore that code is responsible for autodetection of supported browser types. The VCP section needs these bits for the server, so it gets them from the VCI component. dwSettings exact value is server-dependent.
int VcUserPoll(LPVOJD statedata); Checks if the user interface on the Client requested termination.
If VcUserPoll returns a nonzero integer, the Verification Client calls VcShutdown and then exits.
int VcStartup(LPVOID statedata);
Starts up the Verification Client state data and non-portable engine parts. Returns nonzero on error. On receipt of a nonzero integer the Verification Client must immediately exit. VcShutdown does not get called unless VcStartup returned success.
void VcShutdown(LPVOID statedata);
Shuts down the Client, saving any persistent information. All x's must be updated on the VCD structure.
int VcStatusCallback(LPVOID statedata,DWORD status);
Notifies the platform-dependent code of changes to the state machine. The status parameter corresponds to the VCS_* defines below. If this function returns nonzero the Client will call VcShutdown and then exit.
Parameters
#define VCS_INIT 0 #defιne VCS_OPENING 1 #define VCS_NEGOTIATΓNG 2 #defme VCS_LOGGING_rN 3 #defme VCS_SENDING 4 #define VCS_RECEIVTNG 5 #define VCS SHUTTING DOWN 6 #define VCS_ACCESS_DENIED 7 #defιne VCS_COMM_ERROR 8 #defme VCS CONNECTED 9
Portable functions
int VcStartProcess(LPVOιD statedata, VCD * vcd); Entry point to the portable interface.
Class CDebugWsClient
This is a class derived from Dundas WS_Client that allows logging. It is exactly the same but has TRACE calls in the Send and ReceiveData derived functions. Note that modifying this class will allow any other form of comm functionality.
LPSTR AddressToString(DWORD dwAddr);
This function converts an IP address in local byte order into a formatted string (dotted octet notation.) The function uses a static buffer and is not re-entrant.
void FormatVCSerial(DWORD * dw,CString &s)
This function formats a VC serial number into displayable form (Vcaaaabbbbccccdddd.) Input:
(DWORD *): The serial number (4 DWORDs).
Output:
(CString &): The formatted string.
int _cdecl VCEntry(HANDLE hMapping,int * killevent, VCLdrWindows * vcldrWindows,int sleepinterval);
This is the main entry point to the VC Core. It assigns various internal variables in the ThreadData structure and then calls MainPipeThread. After MainPipeThread returns, VCEntry updates the user interface, cleans up, and returns to the loader. DWORD GetCurrenfMinute(void)
GetCurrentMinute returns a 32-bit integer representing the current time in minutes. This is used for random salting.
struct VCI; VCI is the state data structure (LPVOID statedata) that is passed in the VCP functions. VCI maintains all state information for the system-dependent Vc* functions.
The VCI structure contains the following members:
• CDebugWsClient * s; // The connection variable • HICON disconnected, connected; // State icons to plug into the taskbar icon (this will be replaced by the frames for the SurferlD animation)
• ThreadData * t; // The thread data
• LPBYTE data; // VCD raw pointer (memory mapped file)
int VcStartup(LPVOID statedata); VcStartup is the first function called from the portable implementation. It initializes the state variables and prepares the environment for a connection.
The version of VcStartup in VCI loads and initializes the interface to the Netscape plug-in. As with all Vc* functions, the first parameter is a statedata pointer.
Return value:
Nonzero on error. If this function returns nonzero, the portable client immediately returns. VcShutdown is not called.
int VcGefParamSettings(LPVOID statedata,DWORD * dwSettings); This functions sets carrier bits for the CRSPARAMS structure. CRSPARAMS has system-dependent bits to determine the transport.
Input:
(LPVOID): State data.
Output: (DWORD *) settings DWORD. The appropriate bits in this DWORD should be set on return. (int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits.
int VcGetResponseSettings(LPVOID statedata,DWORD * dwSettings);
This function sets carrier bits in the CRSRESPONSE.deRetFlags parameter. CX_HTTP based flags are dependent on system settings, so the flags must be set by the system dependent component.
Input:
(LPVOID): State data.
Output: (DWORD *) settings DWORD. The appropriate bits in this DWORD should be set on return.
(int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits.
int VcSend(LPVOID statedata,LPBYTE data,DWORD dwSize); This function handles the sending of data in a platform independent manner. The VCI implementation uses the CdebugWsClient.Send() function. The function assumes blocking.
Parameters:
(LPVOID): State data. (LPBYTE): Data pointer.
(DWORD): Size. Output:
(int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits.
Int VcReceive(LPVOID statedata,LPBYTE data,DWORD dwSize);
This function handles the receiving of data in a platform independent manner. The VCI implementation uses the
CdebugWsClient.ReceiveData() function. The function assumes blocking. Parameters:
(LPVOID): State data.
(LPBYTE): Data pointer. (DWORD): Size.
Output:
(int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits.
int VcStartCommunications(LPVOID statedata);
This function initiates the connection between the Client and the Server. The format itself is platform-dependent, but the VCP kernel will differentiate between CX_HTTP packets and non-CX_HTTP packets by calling CHAHTTP functions for packets marked CX_HTTP. VcStartCommunications starts the OOB channel.
Parameters:
(LPVOID): State data.
Output:
(int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits.
int VcUserPoll(LPVOID statedata);
VcUserPoll is a event-polling function. If the user indicated that he wishes the process to terminate, VcUserPoll should return nonzero. This function is called frequently as part of the VCP execution, and in particular during each Send and Receive. If VcUserPoll returns nonzero, the VCP will update xs in the VCDATA, call VcShutdown, and then exit.
Note: Do not run VCP in a separate thread and shut it down arbitrarily. This will corrupt the VCDATA. If a session was already established, corrupting the VCDATA will lead to a de- synchronization between the Client and Server, which will forever invalidate that Client and lead to other Bad Things™.
Parameters:
(LPVOID): State data.
Output: (int) nonzero on exit request. If this function returns nonzero, the portable client calls VcShutdown and then exits.
int VcStatusCallback(LPVOID statedata,DWORD status); This function is a helper function to allow the user interface to know when something is happening in the VCP kernel. The VcStatusCallback function receives status notifications whenever anything happens in the VCP kernel, and can update the user interfaec accordingly.
The notifications are:
VCS_ENIT The VCP kernel is initializing. VCS_OPENENG The VCP kernel (with the system-dependent VCI) is opening a comm channel to the Server.
VCS NEGOTIATI The VCP kernel is negotiating a handshake with the Server. (This message may not be sent.)
NG
VCS LOGGENG I The VCP kernel is logging into the Server. (This message may not apply on ^- ~ an OOB channel.)
VCS SENDING The ^CP kernel is sending data (including login messages.)
VCS RECEIVING e VCP kernel is receiving data (including login messages.)
VCS_SHUTTENG_ The VCP kernel is shutting down.
DOWN
VCS ACCESS DE The Server returned an Access Denied error.
NEED
VCS COMM ERR r^le comm imk returned a comm error. (Details may be in the VCI already.)
OR "
VCS CONNECTED T^ Server logged the Client in.
Parameters:
(LPVOID): State data. (DWORD): Message (VCS_*).
Output: (int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits. Note that VcShutdown may also call VcStatusCallback. The output is ignored on a VCS_SHUTTΓNG_DOWN message. void VcShutdown(LPVOID statedata); VcShutdown is responsible for shutting down any state data or communications links maintained by the VCI. VcShutdown may be called at any time after a successful invocation of VcStartup.
Input: (LPVOID): State data. Since VCP never dereferences this pointer, it may be freed at this point.
VcShutdown does not return any value. An exception may be thrown if desired. VCP has no exception handlers, so an exception thrown by VcShutdown will reach the calling function in VCI. (Note that throwing exceptions from other functions may lead to corruption of the VCDATA.)
int VcPersist(LPVOID statedata);
VcPersist triggers a persistent save of the server and client x tables. This is done as an atomic operation during a CX_PERSIST processing. On the client, it is triggered at the next call after a CX_PERSIST flag, to insure the roundtrip. This reduces significantly the probability of a corrupt Client, although does not eliminate it completely. However, if network communications are so unreliable to begin with then persist messages should not be sent to begin with. The final release will not send persist messages if packets can be lost.
Input:
(LPVOID): State data.
Output: (int) nonzero on error. If this function returns nonzero, the portable client calls VcShutdown and then exits. Note that successfully sending the next packet is a signal to the server that the data was successfully persisted, at which point the server will persist its own data and render the previous data invalid.
int MainPipeThread(ThreadData * t);
MainPipeThread is the "shell" that calls the VCP kernel. It contains all exception handlers and the main data flow that surrounds the VCP core.
MainPipeThread calls VcStartProcess from within a try block. It contains exception handlers for all exceptions that may be thrown from within VCP. VCP does not generate any user exceptions.
Input:
(ThreadData *): State data. Output:
(int) nonzero on exception.
void AutoDetect(ThreadData *t);
AutoDetect is responsible for setting the appropriate bits for Internet Explorer and Netscape Navigator in the ThreadData structure.
This function is not currently implemented and simply turns both bits on. int LoadInterfaces(ThreadData *t);
Loadlnterfaces loads the Netscape Navigator and Internet Explorer interface modules as needed. At the moment only the Netscape module is implemented. Loadlnterfaces initializes the Netscape module by creating a new instance of CNpInterface (see NPVC.) The Internet Explorer interface is ignored.
CHAHTTP Functions
CHAHTTP is the interface that transmits CX_HTTP packets to the Server. CHAHTTP uses an extended CRSRESPONSE format and does not include a challenge. In HTTP-only configurations, CHAHTTP is not used; VcSend and VcReceive are used instead.
For structure definitions of the CRS structures, see the CHA section.
class CRSHTTPRESPONSE Definition: class CRSHTTPRESPONSE: public CRSRESPONSE{ private: static WORD ConvTable[256]; public: char dwVc Serial [16]; // VC Serial number
DWORD dwClientIP; // Client IP address
BYTE localsign[16]; // MD5 of the full structure static void InitConvTable(void); static BYTE wordToByte(WORD w); static WORD byteToWord(BYTE i);
LPSTR ConvertToString(void); void ConvertFromString(LPSTR s);
CRSHTTPRESPONSE(CRSRESPONSE &crs);
CRSHTTPRESPONSE(CRSRESPONSE &crs,CRSPARAMS &p); };
CRSHTTPRESPONSE: :CRSHTTPRESPONSE(CRSRESPONSE & crs); CRSHTTPRESPONSE::CRSHTTPRESPONSE(CRSRESPONSE &crs,CRSPARAMS &p); Both of these constructors expand the CRSRESPONSE structure (a component of the XCHG structure) with additional information necessary to track a stateless single-point HTTP response and identify its origin.
Note that everything else in CRSHTTPRESPONSE is portable. These functions are externalized to allow modification in client implementations.
int ProcessHttpResponse(CRSRESPONSE & response,CRSPARAMS & params,LPSTR & cookieheader);
This function is only used on the server.
int Initializelelnterface(void);
This function is not currently implemented and thunks to the CNpInterface constructor.
int lnitializeNetscapelnterface(void);
This function is not currently implemented and thunks to Initializelelnterface.
void SendHttpRequestIe(LPSTR lpIpAddress,LPSTR IpText);
This function is not currently implemented and thunks to CNpInterface: : SendMessage.
Parameters: (LPSTR) lpIpAddress: The string representation of the server IP address
(LPSTR) IpText: Fully formatted text to send through the client's POST interface.
void SendHttpRequestNetscaρe(LPSTR lρIpAddress,LPSTR IpText);
This function is not currently implemented and thunks to SendHttpRequestle.
void SendHttpRequest(CRSRESPONSE & xm,CRSPARAMS & params);
SendHttpRequest is called from the VCP kernel to send data through the HTTP interface whenever the challenge has the CX_HTTP flag set. This function may be replaced in implementation clients. The current version does the following:
1. Convert the CRSRESPONSE to a CRSHTTPRESPONSE. 2. Gets the local IP address.
3. Converts the CRSRESPONSE to a text string using ConvertToString. 4. Depending on the flags set in the CRSPARAMS structure, calls the appropriate transport (Netscape or Internet Explorer.) Currently SendHttpRequest* always calls CNpInterface: :SendMessage.
5.Delete[]s the strings.
SendHttpRequest never reports errors.
SurferED Portable Kernel
The VCP portable kernel contains the common CHA implementation functions. It is relatively portable, although the actual porting has yet to be implemented.
Function List
int VcSendX(LPVOID statedata,LPBYTE data,DWORD dwSize);
This function is an internal wrapper around the VCI function VcSend. It takes the same parameters and calls the external function. However, VcSendX also calls VcStatusCallback(statedata,VCS_SENDlNG) after the successful invocation of VcSend to notify the user interface.
See VcSend for parameter and behavior details.
int VcRecvX(LPVOID statedata,LPBYTE data,DWORD dwSize); This function is an internal wrapper around the VCI function VcReceive. It takes the same parameters and calls the external function. However, VcRecvX also calls VcStatusCallback(statedata,VCS_SENDrNG) after the successful invocation of VcReceive to notify the user interface.
See VcReceive for parameter and behavior details.
int VcWrapper(LPVOID statedata, VCD * _vcd);
Vc Wrapper is a "wrapper" default entry point. It is not currently used.
int VcStartProcess(LPVOrD statedata, VCD * _vcd);
VcStartProcess is the entry point for VCP. VcStartProcess does the following: 1. Assigns local variables.
2. Calls VcStartup to initialize the VCI. 3. Notifies VcStatusCallback of a successful initialization.
4. Calls VcStartCommunications to create the link to the Server.
5. Sends (using VcSendX) the signature and serial number to the Server.
6. Initializes two copies of CRSPARAMS, one for challenges (server p) and one for responses (p), with the serial number.
7. Calls VcGetParamFlags with the p flags member. (The server p does not use its flags member.)
8. Receives the login response from the Server. 9. Checks the response for an Access Denied error. 10. Creates a capabilities flag.
11. Sends the capabilities flag to the Server.
12. Receives a challenge/response pair, with only the challenge filled in.
13. Updates all temporary workspace buffers in the CRSPARAMS structures with current x variables. 14. Gets current time for logging. (The time is not used in calculations.)
15. Calls ProcessChaReq to compute the response to the challenge.
16. Calls CreateChaReq to create a challenge to the server's secret copy. (This is a unique secret that is not global to other clients and can therefore be made persistent.) If CreateChaReq fails and the last x computed for the server is not null, the loop is aborted.
17. If the packet has the CX_PERSIST flag set, calls VcPersist to save the data. (This does not happen in the thread context of VCP.)
18. Sends an XCHG structure containing the challenge and response.
19. Receives a new XCHG structure containing a response and new challenge. If the XCHG.Response is all NULLs the loop is aborted.
20. Loops to step 15.
21. VcStartProcess updates the VCD, calls VcShutdown, and then exits.
Parameters:
(LPVOID): State data. (VCD *): Pointer to the VCD buffer. This buffer is the "live" buffer with the persistent x variables.
Return value:
If VcShutdown was called, the return value is 0. Otherwise it is 1.
Exceptions are not thrown from this function. The function is transparent to thrown exceptions, but does not save x variables if an exception is thrown. An uncaught exception will corrupt the x table and if persistent may invalidate the Client.
CHA Structures and Functions
Most CHA functions are shared between the Client and Server. The CHA functions are divided into two modules: cha and chasvr. Both are included in Client and Server.
class GenericCriticalSection;
This class provides a system-independent critical section. It has no implementation on the Client as the client has only one active thread in CHA.
class CRSRESPONSE;
CRSRESPONSE is the response part of the XCHG structure. CRSRESPONSE has the following definition: class CRSRESPONSE { public:
BYTE md5[16]; // MD5 checksum of the response to the challenge DWORD deRetFlags; // return flags (VCR_*)
}; #define VCR_OK 0 // normal packet
#define VCRJHTTPREQ 0x01 // next request should be a HTTP request
#define VCR_ HTTPRESP 0x02 // the response to this packet will be via HTTP
#define VCRJSTOHTTP 0x04 // no HTTP client is available #define VCR_UA_IE 0x10 // user-agent should be Internet
Explorer
#define VCRJ AJSTSCP 0x20 // user-agent should be Netscape
The Server may choose to ignore VCR_HTTPREQ flags. VCR_HTTPRESP packets must be valid only in the HTTP response. The response in the contained packet is ignored. VCR_HTTPRESP packets may only be sent if the challenge was a CX_HTTP challenge.
The User-Agent flags are currently ignored except for count. The server will expect one HTTP response for each user agent flag present. If the VCRJNOHTTP flag is set the Server may choose to disconnect the client depending on local policy.
class CRSHTTPRESPONSE;
CRSHTTPRESPONSE is the response packet for CX_HTTP challenges. CRSHTTPRESPONSE has two forms: text and binary. The functions to convert CX_HTTP challenges from text to binary and back are part of cha. The actual transmission and construction of CRSHTTPRESPONSE packets is left to the VCI.
Definition: class CRSHTTPRESPONSE: public CRSRESPONSE{ private: static WORD ConvTable[256]; public: char dwVcSerial[16]; DWORD dwClientlP;
BYTE locaIsign[16]; static void InitConvTable(void); static BYTE wordToByte(WORD w); static WORD byteToWordfBYTE i); LPSTR ConvertToString(void); void ConverfFromString(LPSTR s); CRSHTTPRESPONSE(CRSRESPONSE &crs); CRSHTTPRESPONSE(CRSRESPONSE &crs,CRSPARAMS &p);
};
CRSHTTPRESPONSE: ConvTable is a lookup table of 256 BYTE to WORD mappings.
CRSHTTPRESPONSE functions are detailed below.
struct CRSXMITHDR;
CRSXMITHDR is the challenge part of an XCHG packet. It is defined as: struct CRSXMITHDR { WORD Flags;
WORD Size;
BYTE Offset; BYTE RndSize;
WORD Garbage;
CRSXMITHDRO {memset(this,0,sizeof(CRSXMITHDR)); } ;
CRSXMITHDR(CRSXMITHDR &x){ memcpy(this,&x,sizeof(CRSXMITHDR));}; void MakeChecksum(void);
BOOL Verify Checksum(void);
};
The MakeChecksum and VerifyChecksum functions are detailed below. struct XCHG;
A combination of CRSRESPONSE and CRSXMITHDR, the XCHG structure is what actually gets sent out on the wire. struct XCHG {
CRSRESPONSE r;
CRSXMITHDR x;
}; struct CRSPARAMS; CRSPARAMS is the control structure for CHA. CRSPARAMS contains all of the state information that is needed on each side for challenges and responses. struct CRSPARAMS { LPSTR serverlP; DWORD flags;
DWORD dwVCSerial[4];
CRSXMITHDR * httplast;
DWORD chabuf[25];
DWORD chahttp[25];
DWORD chawks[25];
DWORD bitmask;
DWORD timeout; int bufk; int httpk; int wksk;
};
Where: serverEP is the IP address to send the response to. flags contains a combination of VCC_* flags used to determine how to send the response. dwVCSerial contains the VC serial number. httplast contains the last received HTTP challenge. chabuf is the persistent x store. chahttp is the HTTP x store. (This buffer may be out of sync with the others if a HTTP response takes a long time.) chawks contains the current workspace. This buffer is synchronized on a
CX_PERSIST flag, and may be reset on a CX_CLEAR flag. bitmask contains valid bits on the challenge. Only bits that are on in this mask are used in the actual challenge. This prevents overloading a simple machine that can't handle complex iterations. timeout contains the timeout for a specific client on a server. It is not used on the client. bufk is the k value for the chabuf. It is not persistent. httpk is the k value for the chahttp. It is not persistent. wksk is the k value for the chawks. It is not persistent.
VOID CRSXMITHDR: :MakeChecksum(void); This function creates a simple checksum in the garbage bits of the challenge and is used to prevent against packet corruption where relevant. The function is implementation dependent and must be the same on client and server.
BOOL CRSXMITHDR:: Verify Checksum(void); This function checks the checksum created by MakeChecksum and returns TRUE/FALSE on equality. The function is implementation dependent and must be the same on client and server.
BYTE CRSHTTPRESPONSE: :wordToByte(WORD w);
This function reduces a printable WORD in a HTTP text representation to the original BYTE. The algorithm is:
010A BCDO 010E FGHO to ABCD EFGH where 0 and 1 are literal.
Parameters:
(WORD): Input WORD. Return:
(BYTE): Output BYTE.
WORD CRSHTTPRESPONSE: :byteToWord(B YTE i);
This function converts a BYTE to the WORD printable representation using the reverse algorithm. For optimization, the function uses a simple lookup table. The lookup table is stored in the static member ConvTable, which is initialized by a call to InitConvTable on the first invocation of byteToWord.
Parameters:
(BYTE): Input BYTE. Return:
(WORD): Output WORD.
void CRSHTTPRESPONSE: :InitConvTable(void); This function initializes the byteToWord lookup table.
LPSTR CRSHTTPRESPONSE: :ConvertToString(void);
This function converts the CRSHTTPRESPONSE data to a portable 7-bit text unescaped string representation. The string is 115 bytes long and consists of a three byte header followed by a 56 WORD representation of the byte pattern of the CRSHTTPRESPONSE in little-endian unpadded order, converted using byteToWord.
The first three letters are "ACK", which are all illegal bytes in the byteToWord conversion algorithm.
ConvertToString also updates the MD5 localsign member with the current checksum. Return value:
(LPSTR): The text representation. The string is allocated with new[] and must be delete[]d.
void CRSHTTPRESPONSE: :ConvertFromString(LPSTR s);
ConvertFromString converts the inputted string into this. The following validations are done:
. The first three bytes must be "ACK"
• The local signature must match the signed string.
Parameters: (LPSTR): String representation.
void InitializeCha(void);
This function initializes the CHA module. It does the following:
Unitializes the critical section. (Not relevant for the client.) 2. Randomizes an internal tt800 buffer. 3. Initializes the socket library (if relevant) to obtain the local IP address. 4. Sets a trigger variable (isFired) to prevent re-initialization. int CreateChaReq(CRSXMITHDR *cl,CRSRESPONSE & m,CRSPARAMS & params, CRSXMITHDR * last);
CreateChaReq creates a challenge and verifies the response to the previous one. CreateChaReq follows the following steps if the last pointer is not NULL or invalid (which implies that this is the first challenge and does not need to get verified):
1. Check the deRetFlags member of the response to see if this challenge is supposed to get a CX_HTTP response. 2.ProcessChaReq is called to verify the packet with the appropriate buffer (chahttp for a HTTP packet, chawks for a regular packet.) 3. If the packet is bad, the CRSXMITHDR is cleared to all NULLs, which indicates a response failure. The function then returns 0.
The process then continues with creation of a new CRSXMITHDR. This part gets executed on a first call as well. l.If a critical section is necessary, it is asserted.
2. Two new random numbers are issued from a private tt800 loop, and copied into the CRSXMITHDR 3. The garbage member is set with MakeChecksum. 4. The critical section (if any) is released.
5. If the new packet is to be a CX_HTTP packet, CX_CLEAR and
CX_PERSIST are cleared and the new request is saved as httplast in the CRSPARAMs. (Server only.) 6. The function returns TRUE. Parameters:
(CRSXMITHDR *): Buffer to place the new CRSXMITHDR. This must be valid. On error, the contents of this buffer (not the pointer itself) will be zeroed out.
(CRSRESPONSE &): Response from the last challenge. This is ignored if last is NULL or invalid.
(CRSPARAMS &): The CRSPARAMS state data. This will contain the Server state on the Client side.
(CRSXMITHDR *): The last challenge sent. This should be NULL on the first invocation. Return value:
TRUE on success, FALSE on failure or response mismatch. int ProcessChaReq(CRSXMITHDR * cl,CRSRESPONSE & m,CRSPARAMS & params);
ProcessChaReq processes CHA challenges and produces responses. This function may be called in the context of verifying responses or in the context of generating them in the first place.
The function does the following:
1. Checks the checksum on the challenge CRSXMITHDR. Returns 0 immediately if the checksum is invalid. 2. Creates temporary workspace variables. 3-ANDs the challenge with the bitmask, producing the challenge used. 4. Does standard CHA processing as defined above in the CHA algorithm definition. 5. Calculates the MD5 digest of the result of CHA processing and creates a CRSRESPONSE around it. 6. If the CX_HTTP flag is set, sends the CRSRESPONSE using
SendHttpResponse. 7. If CX_PERSIST is set, writes the chawks buffer to chabuf. 8. Returns TRUE.
Parameters: (CRSXMITHDR *) : Received CRSXMITHDR.
(CRSRESPONSE &): Buffer to place the response in.
(CRSPARAMS &): The CRSPARAMS state data. Return value:
TRUE on success, FALSE on failure.
NPVC
NPVC is a Netscape and Internet Explorer compatible plug-in that facilitates the transmission of CXJETTTP packets and adjusts the cookie stream accordingly. The plug-in must be present for a browser to be verified as a user of SurferlD. NPVC communicates with the VC core using a shared memory mapped file. This is not secure but is portable to Windows 95, which does not support local named pipes.
NPVC consists of two modules: the CNpInterface class, which is implemented on the client and plug-in and handles communications, and the NPCORE module, which handles the actual plug- in interface. CNpInterface
CNpInterface has the following structure: class CNpInterface { public: struct NpData { int MsgNumber; int pid; BYTE url[512];
BYTE npd[512];
};
NpData * npd; HANDLE hFile; int CreatePipe();
CNρInterface(); virtual ~CNpInterface(); int SendMessage(LPSTR url,LPSTR data); HANDLE hEvent; };
The structures and functions are defined below:
Struct NpData
This is the data structure that is mapped to the memory-mapped file.
CNpInterface: :CNpInterface() This is the constructor for the pipe. It creates a shared named event called "sibnsplevent", which acts as a change trigger notification on the shared file. The named memory-mapped file "vcnsssharedbufS" is created at the size of the NpData structure. The npd member variable is then set to a pointer to the file.
CNpInterface: :~CNpInterfaceO
This function closes the file and unmaps it.
int CNpInterface: :CreatePipe() Not currently implemented.
int CNpInterface: :SendMessage(LPSTR urLLPST pd) This function sets the text and URL members as defined to the NpData structure pointer npd , which maps them to the other process. It then triggers the event.
NPCore bool Create Vclnstance(void);
Create Vclnstance is called on invocation of the plug-in. It loads the Verification Client executable.
A future version will load the whole VC as a .DLL, which will allow memory sharing without an external buffer.
NPError NPP_Initialize(void)
This function, a standard plug-in function wrapper, registers a window message for the npvc plug-in. The message is caught in the WindowProc.
void _cdecl WindowThreadProc(LPVOID);
This is a watchdog thread that pings the window using the registered message if the event is triggered.
void _cdecl KillProcessProc(LPVOID pidx);
This thread kills the plug-in if the Verification Client shuts down by waiting on the PID and then setting a flag.
void DoThePost(PluginInstance * pi); This function does a POST based on the data found (url, npd) in the shared buffer. It is invoked by the shared registered message.
LRESULT CALLBACK PluginWindowProc( HWND hWnd, UTNT Msg, WPARAM wParam, LPARAM lParam);
This is a standard window proc, except that it calls DoThePost if it receives a registered message from the Thread WindowProc.
VCD Structure
The VCD file is a variable-offset compound file that contains three major sections: the header, the unique, and the core.
See Figure 12 The entire file is encrypted with the System ID.
Signatures
The signatures header has the following structure: struct Signatures { BYTE md5[MD5::DIGESTSIZE]; // md5 digest of whole unencrypted file except for the first 16 bytes DWORD dwSig; // some constant value DWORD dwExeLength; // compressed exe size DWORD dwBigExe; // uncompressed EXE size DWORD dwVcdLength; // uncompressed vcd size
BYTE exeo[MD5::DIGESTSIZE]; // uncompressed exe digest BYTE vcdo[MD5::DIGESTSIZE]; // vcd digest
}; dwSig is not currently used. There is no way of identifying a valid VCD file without checksumming it after it has been decrypted.
Compression is not currently implemented. So the compressed sizes are the same as the uncompressed sizes.
Immediately following the Signatures header is the Core.
Core The core is the Verification Client .DLL. Details on the operation of the core are in the Core sections above.
Unique
The Unique section consists of a VCD structure. struct VCHEADER { DWORD dwSig;
DWORD dwIP;
DWORD dwSerialno[4];
DWORD dwKey[4];
DWORD dwSaltLength; char serverName[32];
}; struct VCD {
VCHEADER vcHeader; DWORD x[25]; DWORD serverx[25]; };
For details of each member, see the VC Core documentation.
System ED Binding
The System ID is designed to be replaced as needed. The current approach is to use strong encryption (where allowed) on a data file, where the key to the file is the System ID. This has the following effects:
• The actual data negotiated between the client and server is completely independent of the System ID. It is impossible to derive the user identity by listening to the data stream, and the server cannot verify the client identity except through the OTP mechanism.
• The System ID can be changed without updating the server.
• Because each System ID can encrypt a different VCD file, and the core can be replaced with one that performs further client verification, a multi-user system is automatically enabled using different user identities. The server does not need drivers for each form of System ID, or even awareness of the identity. (A comment provision on the server is currently available. At a future version there will be support for creating different types of clients in the Server Administrator.)
System IDs can be controlled in two ways: The CSysIDCommand class library, or simple replacement of GetSystemlD.
C Sy sIDCommand
The CSysIDCommand class is a stack implementation that allows many forms of System ID to be linked and called in a series.
The base class is a pure virtual class that implements all of the functionality of the stack, but does not implement the actual ID. The definition is: class CSysIDCommand
{ protected: CString m pData;
CSysIDCommand * m_next;
CString m_machine; virtual LPBYTE ChecksumInternal(LPBYTE buffer)=0; public:
CSysIDCommand(CString lpData,CSysIDCommand * next=NULL) m pData(lpData), m_next(next) { m_machine.Empty(); }; virtual LPBYTE DoChecksum(LPBYTE buffer); // must be 16 bytes long! virtual CString GetMachineName(); virtual void SetMachineName(CString s);
CSysIDCommandO; virtual -CSysIDCommandO;
};
The only function that needs to be overridden is Checksumlnternal. Checksumlnternal takes a 16-byte MD5 checksum, and returns a 16-byte checksum, which may be the same buffer. If the input buffer is NULL, a 16-byte buffer should be allocated with malloc().
The CSysIDCommand constructor keeps a singly linked list of objects, and automatically adds itself to the tail of the list. Calling CSysIDCommand: :DoChecksum will dispatch calls to all members of the list in reverse order on the same buffer. Each list member object will call its own Checksumlnternal function, allowing an independent method of obtaining a unique ID in a modular fashion.
int GetSystemID(BYTE * lpDigest,DWORD & dwErr); The GetSystemlD function itself can be replaced as desired. GetSystemlD is called to determine the decryption and encryption key. The key must be symmetric, unless the encryption algorithm is replaced.
Input:
(BYTE *) lpDigest: A 16-byte buffer to contain the final key. (DWORD &) dwErr: A OS-dependent error code in obtaining the key, or 0 for success.
Output:
(int) ignored.
Encryption Key Guidelines
The key received should be 128 bits long, unique and repeatable. The same GetSystemlD module must appear in createvcs and in vcstartup. The default key uses network, user, OS, and disk characteristics to create a unique repeatable key.
The current algorithm for encryption is CAST- 128, which uses a 128-bit key. Regardless of the algorithm used, GetSystemlD should pass buffers of 128 bits, and algorithms that require more than 128 unique bits are not currently supported. It is not advisable to use constant padding, which will reduce the effectiveness of the encryption key. In countries that do not allow the use of CAST- 128, weaker algorithms are available. Note that since the encryption takes place only locally, export restrictions may not apply (if the server resides in the same country as the client) while domestic encryption restrictions always will. The System ID is the most vulnerable point in the SurferlD implementation; choosing poor System IDs can lead to authentication compromises regardless of the quality of local authentication used. Authentication devices that output less than 128 bits of total unique value or only an index into a known table of users should be combined with other sources if they must be used. They should not be used to seed a RNG as this will reduce the number of unknown bits to a very well known index value and perhaps a specific algorithm for RNG.
External Resources
The SurferlD client depends on a number of class libraries. A brief description of each class library follows:
Ultimate Toolbox
Ultimate Toolbox includes more than 200 MFC classes, adding valuable features that include GUI classes, Framework classes, Utility classes, MAPI classes, OLE classes, Image classes, file classes and more. Ultimate Toolbox has drop-in simplicity and integrates seamlessly with MFC, becoming a part of the MFC framework. The Ultimate Toolbox includes full source code for its more than 200 classes.
UT is used extensively in the MFC-based programs in the Client, including the Client Core (VCI), createvcs, and client generator. Ultimate Toolbox is published by Dundas, Inc., of Toronto, Ontario, Canada, http ://www. dundas . com Crypto
Crypto++ is a cryptographic class library created by Wei Dai, a Canadian national. Crypto++ is a free C++ class library of cryptographic primitives. Currently the library consists of the following, some of which is other people's code, repackaged into classes.
• a class hierarchy with an API defined by abstract base classes
. symmetric block ciphers: IDEA, DES, DES-EDE, RC5, Blowfish, Diamond2, TEA, SAFER. 3-WAY, GOST, SHARK, CAST- 128, Square
• generic cipher modes: CBC, CFB, OFB, counter mode • stream ciphers: SEAL, WAKE, Sapphire, BlumBlumShub
• public key cryptography: RSA, PSA, ElGamal. Diffie-Hellman, BlumGoldwasser, Rabin, LUC, LUCDIF, LUCELG, Elliptic Curve Crvptosy stems padding schemes for public-key systems: PKCS1, OAEP, PSSR • one-way hash functions : SHA, MD5, HAVAL, RIPE-MD 160, Tiger message authentication codes: MD5-MAC, HMAC, XOR-MAC hash functions as ciphers: Luby-Rackoff, MDC pseudo random number generators (PRNG): ANSI X9.17 appendix C,
PGP's RandPool • Shamir's secret sharing and Rabin's information dispersal scheme
DEFLATE (gzip compatible) compression/decompression fast multi-precision integer operations prime number testing and generation various miscellaneous modules such as base 64 coding and 32-bit CRC • A high level interface for most of the above, using a filter/pipeline metaphor
• benchmarks and validation testing
The library was retrieved from a server in Finland and is not in violation of US encryption laws. Due to the modularity of the code, a weaker encryption engine can be used when necessary.
Ultimate TCP/TP
For actual communications we use a class derived from the Dundas Ultimate TCP/IP client class library. The Dundas UTCP/IP 1.0 library is quite buggy; the client class we used is a customized and bug-fixed version of the c wsclnt class.
Ultimate TCP/IP is published by Dundas, Inc. http ://www. dundas . com Rand
We use a customized version of the ttδOO Marsenne Twister algorithm, written by Makoto Matsumoto, matumoto@math.keio.ac.jp, based on ACM Transactions on Modelling and Computer Simulation, Vol. 4, No. 3, 1994, pages 254-266.
MusicMarc uses the newer Marsenne Twister RNG. by Matsumoto and Nishimura, which has a larger cycle and is much faster.
MusicMarc Transfer Protocol
The MusicMarc Transfer Protocol is an out-of-order, restartable system for sending licensed files. The current version of the Protocol is designed for MP3 files, but the protocol is not limited to such files.
Concepts
The Transfer Protocol is an extension to the SurferlD protocol. The Transfer Protocol defines the following terms: File Definition Record (FDR) is the record that defines the file that is to be transferred, including its filename and attributes, as well as size. The FDR also includes the header size, and the trailer size, and the total file size. The FDR packet is used also to calculate the frame transfer order. The frame count and frame size is inferred from the packets transferred after the trailer packet. Each frame packet must be the same size.
Header is the first part of the transferred file. It is sent following the FDR and copied verbatim to the beginning of the file buffer.
Certificate is an implementation defined data block that is inserted immediately following the header. The Certificate is composed of XML fields. Some of these fields are supplied by the Server and some are supplied by the Client.
Trailer is the end of the transferred file. It is sent right after the header. It is written following a reserved space for the frames.
Frames are fixed portions of the file, sent out of order. Frame Transfer Order is the order that frames are transferred in. This order is set by RNG iterations from the FDR packet.
Queue is a track in the progress of transmission. A queue consists of the FDR, header, trailer, and reordered frames. Download Queue is one or more paid queues. Once a track is in a download queue it may be downloaded by the customer at any time. A track is removed from the download queue once the individual queue itself is deleted.
Structures
The MusicMarc message structure is an extended XCHG structure. The format is: struct XCHGEX { XCHG xchg; DWORD dwMmPacketType;
DWOWD dwPayloadSize;
};
Packet types are defined as:
MM_FDR: File definition record MM_HEADER: Header packet MM_CERT: Certificate packet MM FRAILER: Trailer packet MM_FRAME: Frame packet
File definition records consist of the following full structure: struct FDR {
XCHGEX xchg;
TCHAR filename[FILENAME_SIZE];
FILETLME timestamp;
DWORD dwFileLength; DWORD dwHeaderLength;
DWORD dwCertificateType; // currently must be set to CERT_MP3
DWORD dwTrailerLength;
};
Certificates are standard XCHGEX packets containing XML data, which gets merged as defined in the Client implementation.
Frame Ordering
Frames are ordered according to a partial distribution algorithm. Frames are loaded into a two-dimensional array, and the pointers are sorted randomly using a fixed iteration sorting algorithm, the inputs for which are determined by the state of the SurferlD RNG processor at the end of the FDR XCHG processing.
The sorting algorithm for the initial implementation performs the following pseudo-C code: f is a copy of the RNG function with an initial state right after the FDR XCHG packet. The output of f is a DWORD. a is the array of frames. count=f()%(frame_count*2); while (count--) { index=f()%frame_count; index2=f()%frame_count; temp_value=a[index] ; a[index]=a[index2]; afinde ^j^emp^alue; }
This creates a new sequence of frames that is placed in an output queue. The queue is persistent and restartable. If the connection is cut off, the state of the frame sequence is saved until the connection resumes.
Integration The transfer protocol is implemented as part of the MusicMarc Server and Client programs.
MusicMarc Authentication Server
The MusicMarc authentication server is a specific implementation of the SurferlD server with the following extensions: l.Use of the MusicMarc Transfer Protocol as an extension to the SurferlD authentication protocol.
2. The only portions of the site authenticated are MP3 file links. 3. Integrated Billing Server and credit system.
Media Files
To accomplish the specific goals of MusicMarc, the SurferlD filter treats all pages in the site as public access except for the actual track files and the Billing Server. The catalog itself is a SQL database and implementation of the Catalog Server is not part of the scope of this document.
Links are identified as media links by a special URL path. This URL enters the protected media server, which is physically independent from the catalog server. The media server contains only the tracks themselves. A track can only be retrieved from the media server using the MusicMarc Transfer Protocol. The same filename in the HTTP namespace retrieves a plug-in stream that launches the MusicMarc Client and initiates the transfer.
The Billing Server consists of a web site that handles commercial transactions. A customer purchases credit using the Billing Server, which is debited when a file is retrieved. If a customer chooses to use a retailer instead of the primary server, his SurferlD is associated with the retail server rather than the Billing Server and his downloads must be authorized through that server. Trusted servers maintain their own credit balance, which is debited for all transactions that take place through those servers. Security measures on the trusted servers are the responsibility of those servers, although authentication procedures prevent a customer from using the server credit balance directly. In a retail transaction, the retail server and the customer must both have active SurferlD sessions and must notify the Billing Server of intent to purchase and authorize the purchase. Purchase orders are encrypted using SSL and the Billing Server supports any form of commercial purchasing procedure.
Authorization from the Billing Server takes place independently. In the case of retail sites, the logged in customer receives credit from the retail server prior to the purchase in a separate transaction. A download will only proceed if the credit in the account for that customer exceeds the credit needed for that file. The file's price is deducted from the credit when the FDR for the file is sent. The file is then placed in a queue and the user can retrieve it at any time until the entire file is sent. Once the file is sent the queue is deleted and the Media Server will not allow re-downloading of the track unless an administrator or external site credits the customer for the track.
More than one track can be placed on a download queue, although each is sent separately and the discussion below of queues refers to each track queue in a download queue.
Queues
Queues consist of a two-tiered array as defined in the Algorithm section. Queues are held in a linked list that is attached to the end of a Session ID structure and saved in persistent storage for each SurferlD record. A queue record consists of pointers to offsets in the file; the file itself remains in mass storage and does not get loaded into memory or copied to a database.
See Figure 13
Administrator determines the number of frames in each queue. Frame size is a function of the number of frames; smaller frames offer more security than larger ones, while larger frames offer increased performance and faster download time. Frame count can be determined on a per-file basis and can match the number of MP3 frames that exist in the original file.
Note the queue reordering is a form of cryptography only suited for unordered streams and that use of reordering is not recommended for video, structured data, or text.
A download queue is a singly linked list of queues that is persisted into the .customer database until it is emptied.
Certificates of Authenticity (COA)
A COA is divided into two parts: the Song Record and the License. The Song Record consists of data that identifies the track to a player or user. The License consists of data that identifies the licensee and the owner of the track.
The Certificate record sent by the Server contains the Song Record and some pans of the License. The rest of the License is inserted by the Client. Exact details of field descriptions are implementation-dependent. A sample follows:
<XML>
<UFI>9</UFI> <SongRecord>
<Title>Hero </Title>
<Artist>Mariah Carey</Artist>
<Album>Music Box</Album>
<Year>1993</Year> <Comment>Sample Certificate Record</Comment>
<Genre> 13.Pop</Genre> </SongRecord> <License>
<SurferID>SD00O00O00OOOOO000</SurferID> <Username>j qp</Username>
<CreditCard>1234-5678-9012-3456</CreditCard>
<Expiration>01/O0</Expiration>
<CardHolder>John Q. Public</CardHolder>
<Email>jqp@public.com</Email> <ServerName>MusicMarc Demo Server</ServerName>
<ServerType>Retail</ServerType>
<ServerID>SD0000000000000000</ServerID>
<Publisher>Unspecified Record Company</Publisher>
<LicenseType>l. Single User</LicenseType> </License>
<ENCODER>MusicMarc 1.00</ENCODER> </XML>
The UFI field is inserted by the Client and must appear before the Song Record and License in the current client implementation.
User Interface
MusicMarc uses the standard SurferlD user interface.
MusicMarc Chaffing Algorithm
The chaffing algorithm uses a local derivative of the shared secret. The state of the shared secret is stored in a protected database at the point of the FDR transmission ~ the same point that determines reordering. The primary key of that table is known as the UFI and corresponds to the UFI record in the COA.
The shared secret state is used to initialize a new Mersenne Twister engine, the output of which forms the chaff. Chaffing consists of taking a fixed number of records out of order and XORing the sample data with a random number stream generated by a Mersenne Twister engine using a classic OTP algorithm. [This is just an example of chaffing; the invention is not bound to this specific implementation.] MP3 consists of frame headers and actual sample data. Only the samples themselves are chaffed.
Only a fixed percentage of frames is chaffed. (See the reference implementation of the chaffer for details.) Since a frame corresponds to a very small amount of track time, frames are rarely chaffed individually. Instead, a number of frames will be chaffed in a frame group.
Decoding the file is simply a matter of repeating the chaffing process with the same seed values.
MusicMarc Client Implementation
The Client consists of five major parts: 1 • Authentication engine. 2. Download client. 3. Playback/decoding unit. 4. Operating system hooks. 5. User interface.
Component Map
See Figure 14
14.1 Authentication Engine: The authentication engine is a standard SurferlD Verification Client, with MusicMarc extensions as described in the chapter on the MusicMarc server. 14.2 System ED: A System ID can be a password, a set of computer metrics, a smart card, a biometric reading, or a network ID, or any combination of the above.
14.3 Download Client: The download client receives data from the authentication engine, which actually communicates with the server. The download client is responsible for chaffing the file and writing it to disk in the correct order. It does not communicate with the Protected Storage system so as to minimize points of attack on the client end.
The download client resides in a separate address space from the authentication engine and communicates using IPC mechanisms depending on the target platform.
14.4 Protected Storage: The protected storage system is the same as the one in SurferlD shared secrets. It is guarded by the System ED.
14.5 Chaff Decoder: The Chaff Decoder integrates with MP3 players and supplies to them an unchaffed MP3 stream. There are two primary mechanisms for integration: file monitor, and output monitor.
14.6 Decode File Monitor: A file monitor requires a shared .DLL that watches for file opens and correlates them with processes. If an MP3 file is opened by a player, then reads from that file are transparently replaced with reads from the unchaffed data buffer. Since the chaffed and unchaffed buffers are exactly the same size there will be no harmful effects except for a slight decrease in performance.
The file monitor hooks eight functions (all functions hooked will be hooked in both Unicode and ANSI variations): CreateFile, OpenFile, ReadFile, CloseHandle, CreateFileMapping, MapViewOfFile, MapViewOfFileExm UnMapViewOfFile.
A hook is accomplished using code replacement in memory. Since each imported .DLL function in a Win32 application has an entry in a jump table, redirection of the entry is quite simple and requires merely overwriting the address in the import jump table with the monitor function.
14.7 CreateFile Hook: The CreateFile function is used in Win32 applications to create and open files or devices. If a MP3 filename is passed to the CreateFile function, the file is first opened internally by the monitor. If the file has a UFI field, it is copied to an anonymous memory-mapped file and decoded. The original handle is recorded in a local lookup table for optimization.
14.8 Memory Mapped File Hook: Some MP3 players may use memory-mapped files. In such cases the players will receive a direct pointer to the memory mapped buffer. CloseHandle and UnMapViewOfFile will be monitored as well to prevent double freeing of handles. 14.9 ReadFile Hook: This simply emulates a standard ReadFile, reading from the decoded buffer instead of the actual buffer. The file position is incremented as if it was a real read.
14.10 CloseHandle Hook: This closes both the original and the decoded handles for the object.
14.11 Monitor Criteria: Not every program will have monitoring enabled. To enable monitoring for a program, a hidden database of the following criteria will be maintained and updated by MusicMarc:
1.Filename of the executable or .DLL that will be hooked. 2. File size and datestamp.
3. Version number in the VERSIONTNFO of the executable image.
The delivery mechanism will be via a secure http download that can be updated in a fashion similar to virus definitions in anti-virus software. All MP3 playback programs available will be in the database. Any program not in the database will not be monitored and will only receive chaff.
The initial reference version of MusicMarc will utilize a file filter.
14.12 Output Monitor: An output monitor requires a change in the chaffing system. Instead of chaffing actual MP3 data, the chaffer will decode selected frames and chaff the underlying waveform. Then the chaff decoder monitors the output wave device and unchaffs the PCM data as it is sent to the speakers. This is more secure but must be done properly to prevent decrease in quality and will not be done within the timeframe needed for the first version of MusicMarc.
The invention has been described with a certain degree of particularity, but those versed in the art will readily appreciate that various alterations and modifications may be carried out, without departing from the scope of the following claims:

Claims

CLAIMS:
1. A method for authenticating two peers within an authentication protocol, the peers are associated with a shared secret common to said peers and an identical randomization algorithm that utilizes a pseudorandom generator, the method includes the following steps: a) in response to a command received from a challenging peer from among said peers, the other peer, constituting a challenged peer, applying said randomization algorithm seeded by said shared secret or derivative thereof so as to obtain one or more output; b) the challenged peer applying transformation to at least said output and to data of at least one data packet so as to obtain a response; c) transmitting the at least one packet and said response or derivative thereof to said challenging peer; d) the challenging peer applying said algorithm as stipulated in steps (a) and (b) and compares the so-obtained response to that received from the challenged peer and in the case of match said challenged peer is authenticated.
2. The method of claim 1, further comprising: e) repeating said steps (a) to (d) n (n 1) cycles; in each cycle the output obtained in the previous cycle or derivative thereof serves as the shared secret seeded to said randomization algorithm;
3. The method according to claims 1 or 2, wherein said steps (a) to (d) are performed by both peers, each constituting both challenging and challenged.
4. A method for the protected distribution of a file over a network, from a sending peer to a receiving peer, comprising: (a) applying authentication between said peers according to any one of claims 1 to 3;
(b) dividing the file into first order series of packets at the first peer side; (c) applying a reordering algorithm to the first series so as to obtain a second order series of packets; said reordering of algorithm utilizes one or more of said outputs or derivatives thereof;
(d) transmitting said packets according to the second order series;
(e) receiving the packets at the receiving peer side; (f) reordering said packets into the original first order using said outputs or derivatives thereof; and
(g) using said file.
5. The method according to claim 4, further comprising: (a) chaffing selected packets of said first or second order series of packets;
(b) in the receiving side, undoing said chaffing whilst using said file on- the- fly.
6. The method according to anyone of claims 1 or 2 wherein the shared secret includes or is derived using at least one item selected from the list that includes: name of receiver, receiver's credit card number, receiver's bank account number, receiver's address, a system signature, a bio-metric signature, a digital signature, a common datum.
7. The method according to anyone of Claims 1 to 6, wherein said transformation algorithm is selected from the list that includes: RSA, DES,
Mersenne Twister, MD5 hash, a cipher algorithm, a one way hashing function, a shared secret dependent function, a two way encryption function, a pseudo-random number generation function.
8. The method according to any one of claims 2 or 7 wherein the file is watermarked.
9. The method according to any one of claims 2 to 8 wherein the file includes contents interpretable as at least one of the list that includes the following: music, text, graphics, video, hypertext, or multimedia.
10. The method accordmg to any one of claims 2 to 9, wherein the file is compressed or encrypted.
11. A method for chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section, comprising the following steps:
(a) deriving at least one chaff key from at least the COA section or portion thereof;
(b) chaffing selected portion of said data section using said at least one chaff key.
12. The method according to Claim 11 further comprising the step of:
(c) repeating said steps (a) and (b) n cycles; in each cycle for a different COA and chaff key.
13. A method for de-chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section; selected portion of said file being chaffed by at least one chaff key derived from at least said COA section or portion thereof , the method comprising the steps of: (a) deriving the at least one chaff key from at least the the COA section or portion thereof ; and (b) de-chaffing said selected portion using said at least one key.
14. The method according to Claim 13, repeating said steps (a) and (b) n cycles; in each cycle for a different COA and chaff key.
15. A system for authenticating two peers within an authentication protocol, the peers are associated with a shared secret common to said peers and an identical randomization algorithm that utilizes a pseudorandom generator, the system comprising:
(a) in response to a command received from a challenging peer from among said peers, the other peer, constituting a challenged peer, applying said randomization algorithm seeded by said shared secret or derivative thereof so as to obtain one or more output;
(b) the challenged peer applying transformation to at least said output and to data of at least one data packet so as to obtain a response; (c) transmitter, transmitting the at least one packet and said response or derivative thereof to said challenging peer;
(d) the challenging peer applying said algorithm as stipulated in steps (a) and (b) and compares the so-obtained response to that received from the challenged peer and in the case of match said challenged peer is authenticated.
16. A system for chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section, the system comprising:
(a) a module for deriving at least one chaff key from at least the COA section or portion thereof, (b) a module for chaffing selected portion of said data section using said at least one chaff key.
17. A system for de-chaffing a file, the file includes a Certificate Of Authenticity (COA) section and a data section; selected portion of said file being chaffed by at least one chaff key derived at least from said COA section or portion thereof, comprising
(a) deriving the at least one chaff key from at least the COA section or portion thereof; and
(b) de-chaffing said selected portion using said at least one key.
18. For use in the method according to anyone of Claims 1 to 10, a challenging peer.
19. For use in the method according to anyone of Claims 1 to 10, a challenged peer.
PCT/IL1999/000497 1998-09-09 1999-09-09 Method and system for the protected distribution of network files WO2000014925A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU58810/99A AU5881099A (en) 1998-09-09 1999-09-09 Method and system for the protected distribution of network files

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IL126147 1998-09-09
IL12614798A IL126147A0 (en) 1998-09-09 1998-09-09 Method and system for the protected distribution of network files

Publications (2)

Publication Number Publication Date
WO2000014925A2 true WO2000014925A2 (en) 2000-03-16
WO2000014925A3 WO2000014925A3 (en) 2000-07-06

Family

ID=11071949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL1999/000497 WO2000014925A2 (en) 1998-09-09 1999-09-09 Method and system for the protected distribution of network files

Country Status (3)

Country Link
AU (1) AU5881099A (en)
IL (1) IL126147A0 (en)
WO (1) WO2000014925A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1542399A1 (en) * 2002-09-16 2005-06-15 Legend (Beijing) Limited The method for connecting devices in dynamic family networking
CN101425925B (en) * 2002-09-06 2011-04-06 提莱波斯公司 Method, system and apparatus for providing authentication of data communication
WO2014028712A1 (en) * 2012-08-15 2014-02-20 Telecommunication Systems, Inc. Device independent caller data access for emergency calls

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0636963A2 (en) * 1993-07-30 1995-02-01 International Business Machines Corporation Authentication system using one-time passwords
EP0693836A1 (en) * 1994-06-10 1996-01-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols.
US5659569A (en) * 1990-06-25 1997-08-19 Qualcomm Incorporated Data burst randomizer
EP0794640A2 (en) * 1996-01-19 1997-09-10 General Instrument Corporation Of Delaware Virtual authentication network for secure processors

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659569A (en) * 1990-06-25 1997-08-19 Qualcomm Incorporated Data burst randomizer
EP0636963A2 (en) * 1993-07-30 1995-02-01 International Business Machines Corporation Authentication system using one-time passwords
EP0693836A1 (en) * 1994-06-10 1996-01-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols.
EP0794640A2 (en) * 1996-01-19 1997-09-10 General Instrument Corporation Of Delaware Virtual authentication network for secure processors

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OORSCHOT VAN, MENEZES, VANSTONE: "HANDBOOK OF APPLIED CRYPTOGRAPHY" 1997 , LIBRARY OF CONGRESS CATALOGING-IN-PUBLICATION DATA , NEW YORK XP002134672ISBN: ISBN 0-8493-8523-7 page 395, paragraph 10 -page 397, paragraph 2 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101425925B (en) * 2002-09-06 2011-04-06 提莱波斯公司 Method, system and apparatus for providing authentication of data communication
EP1542399A1 (en) * 2002-09-16 2005-06-15 Legend (Beijing) Limited The method for connecting devices in dynamic family networking
EP1542399A4 (en) * 2002-09-16 2009-07-29 Lenovo Beijing Ltd The method for connecting devices in dynamic family networking
WO2014028712A1 (en) * 2012-08-15 2014-02-20 Telecommunication Systems, Inc. Device independent caller data access for emergency calls
US9313638B2 (en) 2012-08-15 2016-04-12 Telecommunication Systems, Inc. Device independent caller data access for emergency calls

Also Published As

Publication number Publication date
WO2000014925A3 (en) 2000-07-06
IL126147A0 (en) 1999-05-09
AU5881099A (en) 2000-03-27

Similar Documents

Publication Publication Date Title
EP1072143B1 (en) System for keying protected electronic data to particular media to prevent unauthorized copying
US6859791B1 (en) Method for determining internet users geographic region
JP4549673B2 (en) Method and system for preventing unauthorized re-recording of multimedia content
KR100374524B1 (en) Secure electronic content distribution on cds and dvds
EP1625479B1 (en) Method and system for controlled media sharing in a network
US7213005B2 (en) Digital content distribution using web broadcasting services
US6574609B1 (en) Secure electronic content management system
US7228437B2 (en) Method and system for securing local database file of local content stored on end-user system
EP1665717B1 (en) Method for preventing unauthorized distribution of media content
JP4463998B2 (en) Protected online music distribution system
US7962413B2 (en) End-user system of preventing unauthorized rerecording of multimedia content
US7383228B2 (en) Method and system for preventing unauthorized rerecording of multimedia content
US7246246B2 (en) System for keying protected electronic data to particular media to prevent unauthorized copying using a compound key
US7110984B1 (en) Updating usage conditions in lieu of download digital rights management protected content
US7188085B2 (en) Method and system for delivering encrypted content with associated geographical-based advertisements
US7590866B2 (en) Super-distribution of protected digital content
JP2001160003A (en) Method and device for uniquely identifying customer purchase in electronic distribution system
JP4340013B2 (en) Method and apparatus for securely delivering content over a broadband access network
WO2001061913A2 (en) Network-based content distribution system
US20140208446A1 (en) Reporting information about users who obtain copyrighted media using a network in an unauthorized manner
US20030233563A1 (en) Method and system for securely transmitting and distributing information and for producing a physical instantiation of the transmitted information in an intermediate, information-storage medium
CA2338414C (en) Secure electronic content management system
WO2000029928A1 (en) System for keying protected electronic data to particular media using a compound key to prevent unauthorized copying
WO2000030319A1 (en) System for keying protected electronic data to particular media to prevent unauthorized copying using asymmetric encryption and a unique identifier of the media
WO2000014925A2 (en) Method and system for the protected distribution of network files

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase