WO2001035569A1

WO2001035569A1 - Method and system for data encryption and filtering

Info

Publication number: WO2001035569A1
Application number: PCT/US2000/030135
Authority: WO
Inventors: Jonathan Levin; Uriel Ginsburg
Original assignee: Network Privacy.Com, Inc.
Priority date: 1999-11-12
Filing date: 2000-11-13
Publication date: 2001-05-17

Abstract

A system and a method for securely transmitting data from, and receiving data by, a computer on a network such as the Internet. The system and method of the present invention provide a general security solution for such data transmissions, which is not dependent upon the type of application or the type of data transmitted. In addition, since the system and method encrypt data prior to transmission over the network (14), which is only then decrypted upon receipt by the receiving computer (16), the system and method also provide anonymity and privacy for both identification of the sending and receiving parties, the data itself which is sent, and even the type of application which created the data.

Description

APPLICATION FOR PATENT

Title: METHOD AND SYSTEM FOR DATA ENCRYPTION AND

FILTERING

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a system and method for data encryption

and filtering, and in particular to a platform for Heterogeneous Integrated Data

Encryption which enables the security of a plurality of different types of data to

be guaranteed.

Large amounts of data are transmitted on a daily basis through computer

networks, and particularly through the Internet. Perhaps owing to its origins as

an academic tool, the Internet is geared toward the efficient transport of data

from one endpoint to one or more endpoints, and not on the security of such

data. Therefore, unauthorized users or "hackers" have unfortunately gained

relatively easy access to data transported on the Internet. Many such

unauthorized users may not have criminal intent, yet may still inflict damage,

by intruding on privacy, disrupting computer systems and defacing Web sites.

More serious crimes may have consequently more serious damage, such as

information theft and/or alteration, in which proprietary, commercial

information may be stolen and sold or misused. In addition, computer damage

may occur requiring the repair of damages inflicted by unauthorized users on

computer systems. Financial damages are also possible, as many credit card transactions are made over the Internet, such that the theft of credit card

numbers and information has become a common criminal practice.

These problems stem from the infrastructure of networks in general, and

of the Internet in particular. The infrastructure of the Internet is actually not

peer to peer. Rather, when two points exchange any information, the

communication is relayed over a number of intermediary points, and in actuality

is not peer to peer. Hence, anybody with access to any intermediate point may,

by a technology commonly known as "sniffing^", employ simple tools to

eavesdrop while remaining undetectable. Sniffing is by far easier in local area

networks (LAN), wherein data relayed across the network is visible to any

entity connected to it.

To add to the inherent drawbacks of such a structure, any "man in the

middle" may easily assume the role of either of the parties, and falsely engage

in the communication. Should that communication involve the transfer of

sensitive information, such as trade secrets, proprietary information, credit card

numbers, and so forth, the security of that information would be greatly

jeopardized.

Securing data transport over commonly used insecure media usually

requires several key points to be addressed. First, access control must be

provided, such that only members of the trusted set of entities are allowed to

access communication links. Authenticity must be guaranteed, by preventing

third parties from fabricating or counterfeiting messages. In addition, the

communication channel should be secured against miscellaneous "Denial of Service^" attacks, thereby ensuring that the legitimate users have access to the

channel. Confidentiality is also important, by preventing third parties from

intercepting communication or eavesdropping. No one but the two participants

should be aware of the contents. With regard to data integrity, the data received

on one endpoint should be guaranteed to be the data sent from the other

endpoint, such that the data has not been tampered or otherwise altered.

Privacy is needed to prevent interruptions from malicious entities.

In order to protect the security of the data transported on the Internet,

many different solutions have been proposed. However, every single solution

available today specifically protects a single aspect of Internet, or requires a

special, complex action from the user. For the simple Internet user, who may be

either a dial-up user at home, or a corporate executive in a business office, these

data-protection schemes are sometimes difficult to use and even to understand.

There is no solution today which provides a global solution by acting

heterogeneously, regardless of the environment and operating system of the

computer. Rather, specific and separate solutions are provided for each

application, and sometimes, for each operating system. Data security is inherent

only in specifically designed applications or protocols, such as SSL for Web

browsers or in protocols which are still under development, such as IPSEC.

Such data security is not, however, integrated into the foundation of the

Internet, which is the TCP/IP protocol suite.

A common mechanism for data security is encryption of the data. There

is no comprehensive security scheme which provides encryption for all data. regardless of content or type. At present, users wishing to encrypt sensitive data

must install several software packages, complicating data security.

In addition, the encryption is often incomplete: while the actual content

of the communication may be encrypted, the type of data transfer typically is

not encrypted. For example, HTTP transfers clearly remain HTTP data even

when using SSL. Encrypted e-mail (electronic mail) is still easily classifiable as

such, since encryption solutions such as PGP (Pretty Good Privacy; a freely

distributed public key encryption software, developed by Phil Zimmerman) do

not encrypt e-mail message headers, so the parties involved are still known.

Sometimes, the actual connection itself must be kept secret. Hence, there is a

genuine, yet unaddressed need for such protection.

A more useful solution for addressing these needs would operate at the

level of the TCP/IP layer, or through similar network protocols. By operating

at the level of packet transport on the network, the solution could be used for

substantially any type of data, regardless of the actually software application

which generated the data. Furthermore, the solution would be sufficiently

comprehensive that the user would only need to install a single type of software

package in order to obtain the security. Thus, this solution would provide a

general security platform for data being transmitted and/or received, which

would be simple to install and use. Unfortunately, such a solution is not

currently available.

There is thus a need for. and it would be useful to have, a system and a

method for providing security for data transmitted through a network, such as the Internet, which is a general security solution and which is not dependent on

the type of application or the type of data, such that the system and method of

the present invention can provide a single overall security solution for data

transmitted to and from the computer of a user.

SUMMARY OF THE INVENTION

The present invention is of a system and a method for securely

transmitting data from, and receiving data by, a computer on a network such as

the Internet. The system and method of the present invention provide a general

security solution for such data transmissions, which is not dependent upon the

type of application or the type of data transmitted. In addition, since the system

and method of the present invention encrypt data prior to transmission over the

network, which is only then decrypted upon receipt by the receiving computer,

the system and method of the present invention also provide anonymity and

privacy for both identification of the sending and receiving parties, the data

itself which is sent, and even the type of application which created the data.

According to a preferred embodiment of the present invention, the

system and method of the present invention provide a software interface layer

between the computer and the network, which is integrated at the network layer.

Therefore, the encryption is absolutely transparent to the transport and

application layers above the software interface layer. Data can therefore be

encrypted regardless of protocol or any other attribute. Existing solutions which

are known in the background art often incorporate themselves at the application level, giving a pinpoint solution which is limited in scope, in contrast to the

software interface layer of the present invention.

According to the present invention, there is provided a system for secure

transmission of data on a network, the system comprising: (a) a first computer

connected to the network for transmitting the data on the network; (b) a first

interface layer being operated by the first computer and for being located

between the first computer and the network, such that all data transmitted from

the first computer passes through the first interface layer before being

transmitted on the network, and for encrypting the data to form encrypted data;

(c) a second computer connected to the network for receiving the encrypted

data on the network; and (d) a second interface layer being operated by the

second computer and for being located between the second computer and the

network, such that all data received from the network passes through the second

interface layer before being received by the second computer, and for

decrypting the encrypted data to form decrypted data, the decrypted data being

passed to the second computer.

According to another embodiment of the present invention, there is

provided a method for secure transmission of data from a first computer to a

second computer on a network, the method comprising the steps of: (a)

requesting a connection for data transmission by a first software application

operated by the first computer to a second software application operated by the

second computer through the network; (b) generally encrypting data received

from the first software application before transmission on the network to form encrypted data, such that the data is encrypted at a network layer; (c)

transmitting the encrypted data on the network: (d) receiving the encrypted data

by the second computer; (e) generally decrypting the encrypted data to form

decrypted data at the network layer; and (f) passing the decrypted data to the

second software application.

According to still another embodiment of the present invention, there is

provided a software interface layer for encrypting data transmitted from a

computer and for decrypting data received by the computer, the software

interface layer comprising: (a) an encryption module for encrypting and

decrypting the data; and (b) a socket- forming module for forming a socket

between a standard port and any software application operated by the computer,

such that the encrypted data is transmitted through the socket and the decrypted

data is received by the software application.

Hereinafter, the term "computer platform" refers to a particular computer

hardware system or to a particular software operating system. Examples of

such hardware systems include, but are not limited to, personal computers (PC),

palmtop computers, handheld and portable computers, Macintosh ^rΛ computers,

mainframes, minicomputers and workstations. Examples of such software

operating systems include, but are not limited to, UNIX, VMS, Linux,

MacOS™, DOS, one of the Windows™ operating systems by Microsoft Corp.

(USA), including Windows NT™, Windows 3.x™ (in which "x" is a version

number, such as "Windows 3.1™"), Windows CE™, Windows95™, and

Windows98™, as well as any suitable operating system for embedded units or palmtop/handheld type portable computers.

For the present invention, a software application could be written in

substantially any suitable programming language, which could easily be

selected by one of ordinary skill in the art. The programming language chosen

should be compatible with the computer platform according to which the

software application is executed. Examples of suitable programming languages

include, but are not limited to, C, C++ and Java.

In addition, the present invention could be implemented as software,

firmware or hardware, or as a combination thereof. For any of these

implementations, the functional steps performed by the method could be

described as a plurality of instructions performed by a data processor.

Hereinafter, the term "Web browser" refers to any software program

which can display text, graphics, or both, from Web pages on World Wide Web

sites. Hereinafter, the term "Web page" refers to any document written in a mark-

up language including, but not limited to, HTML (hypertext mark-up language)

or VRML (virtual reality modeling language), dynamic HTML, XML (extended

mark-up language) or related computer languages thereof, as well as to any

collection of such documents reachable through one specific Internet address or

at one specific World Wide Web site, or any document obtainable through a

particular URL (Uniform Resource Locator). Hereinafter, the term "Web site"

refers to at least one Web page, and preferably a plurality of Web pages, virtually

connected to form a coherent group. Hereinafter, the phrase "display a Web page" includes all actions

necessary to render at least a portion of the information on the Web page

available to the computer user. As such, the phrase includes, but is not limited

to, the static visual display of static graphical information, the audible

production of audio information, the animated visual display of animation and

the visual display of video stream data.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, with

reference to the accompanying drawings, wherein:

FIG. 1 is a schematic block diagram of an exemplary system according

to the present invention;

FIG. 2 is a schematic block diagram of an exemplary software interface

layer according to the present invention;

FIG. 3 is a schematic block diagram of a background art WinSock™

architecture;

FIG. 4 is a schematic block diagram of a background art protocol chain;

FIGS. 5 A and 5B are schematic block diagrams of a background art

transport driver interface architecture (Figure 5A) and a background art

network driver interface architecture (Figure 5B);

FIG. 6 is a flowchart of an exemplary method for creating a socket

according to the present invention; FIG. 7 is a flowchart of an exemplary method for establishing a

connection according to the present invention; and

FIGS. 8A and 8B are flowcharts of exemplary methods for intercepting

send () and recv () system calls according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is of a system and a method for securely

transmitting data from, and receiving data by, a computer on a network such as

the Internet. The system and method of the present invention provide a general

security solution for such data transmissions, which is not dependent upon the

and method of the present invention encrypt data prior to transmission over the

network, which is only then decrypted upon receipt by the receiving computer,

the system and method of the present invention also provide anonymity and

privacy for both identification of the sending and receiving parties, the data

itself which is sent, and even the type of application which created the data.

According to a preferred embodiment of the present invention, the

system and method of the present invention provide a software interface layer

between the computer and the network, which is integrated at the network layer.

Therefore, the encryption is absolutely transparent to the transport and

application layers above the software interface layer. Data can therefore be

software interface layer of the present invention.

According to another preferred embodiment of the present invention, a

secure proxy is provided for the purpose of supplying users with further

anonymity and privacy. According to the background art, a proxy is a trusted

mediator. Instead of connecting to the actual endpoint. a host may opt to

connect to the proxy instead, and allow the proxy to perform the second stage

connection. Such a proxy connection is usually performed when the proxy

enjoys a wider bandwidth, or if the proxy uses a caching mechanism which

efficiently reduces network traffic. The secure proxy of the present invention

provides a different functionality, in which the identity of both parties may be

kept secret. Preferably, the secure proxy of the present invention may provide a

plurality of different modes of operation.

For example, the secure proxy of the present invention may act as a

connection bouncer, by acting as a relay and thereby masking the actual

endpoints of the connection, while providing encryption. Sniffing would thus

not only fail to discern the communication content or type, but in addition

would not be able to determine the identity of either of the parties involved.

Another optional but preferred mode for the secure proxy of the present

invention is as a mediator which negotiates between the two endpoints. This is

useful when the two parties do not already "know" each other for performing

the connection. The secure proxy is able to certify each party to the other,

thereby preventing the parties from being subjected to a "Man in the Middle" attack. In this preferred mode of operation, the secure proxy only negotiates the

initial connection between the two parties. Once the negotiation is complete, the

two parties are able to independently contact each other.

By seamlessly integrating both connection security and anonymity as

transparent components within existing operating systems, the system and

method of the present invention, and particularly the preferred embodiment of

the software interface layer, provides a number of innovative and advantageous

features over any existing solution known in the background art. For example,

the system and method of the present invention are able to encrypt data

regardless of the content of the data, or of the type of data or of the application

which created the data. In the preferred embodiment of the software interface

layer which resides at the network layer for controlling all data communication

to and from the computer, the present invention provides a modular solution. In

addition, the system and method of the present invention can be used with

substantially any type of encryption algorithm or method, such that the present

invention is not limited to any one type of encryption.

Furthermore, the system and method of the present invention potentially

allow two or more computers to communicate securely, such that intervention

by an outside user through a "Man in the Middle" attack is prevented. Indeed,

if the user of the computer sets the policy of the computer such that only

communications from computers with such secure software interface layers are

accepted, the present invention may also act as a type of firewall. Thus, the

system and method of the present invention may also provide general security for the data stored on the computer of the user and for the operation of that

computer.

The system and method of the present invention also provide anonymity

and privacy of identity. The secure proxy of the present invention provides

both security and anonymity, unlike background art solutions in which one may

be achieved at the expense of the other. Furthermore, in the background art,

different types of information are available about such a transaction, such as the

type of application data and so forth, even with currently available "secure"

transaction mechanisms. Thus, only the system and method of the present

invention provide a complete and general security solution, which is optional

able to provide anonymity and privacy as well.

The principles and operation of the method according to the present

invention may be better understood with reference to the drawings and the

accompanying description.

Referring now to the drawings, Figure 1 shows a schematic block

diagram of an exemplary system according to the present invention, while

Figure 2 shows a schematic block diagram of an exemplary implementation of

the present invention as a software interface layer (also shown in Figure 1).

As shown in Figure 1 , a system 10 features a user computer 12,

connected to a network 14 which may be the Internet, for example. User

computer 12 exchanges data with an endpoint computer 16, which is also

connected to network 14. User computer 12 and endpoint computer 16 each

operate a software interface layer 18. which sits between network 14 and each of user computer 12 and endpoint computer 16. Software interface layer 18

encrypts all data which is transmitted from each of user computer 12 and

endpoint computer 16, while decrypting all data which is received by each of

user computer 12 and endpoint computer 16. Software interface layer 18

preferably performs such encryption regardless of the type of data and/or of the

application which created the data. More preferably, software interface layer

18 performs such encryption in addition to any other encryption which may

have been performed on the data by an application-specific encryption

mechanism. Thus, the encryption provided by software interface layer 18 is

preferably transparent to the user, as well as to the operation of each of user

computer 12 and endpoint computer 16.

Figure 2 shows the interaction of the software interface layer of the

present invention with a few exemplary applications being operated by the user

computer of Figure 1, it being understood that such an interaction could be

performed with substantially any application of any computer. As shown, user

computer 12 operates a plurality of exemplary software applications, including

a Web browser 20, an e-mail (electronic mail) software program 22, a

networking application 24, a Telnet application 26 and a FTP (file transfer

protocol) application 28. Of course, other software applications could be

operated in addition to, or in place of, these exemplary applications, which are

given only to illustrate the operation of the present invention.

Software interface layer 18 is also operated by user computer 12, and as

previously described, sits between user computer 12 and the network (not shown) to which user computer 12 is connected. Software interface layer 18

interacts with each of Web browser 20. e-mail (electronic mail) software

program 22. networking application 24, Telnet application 26 and FTP (file

transfer protocol) application 28. In particular, software interface layer 18

receives data from each application for transmission beyond user computer 12,

and encrypts this data before transmission through the network. In addition,

software interface layer 18 also decrypts data received by user computer 12

before such received data is passed to a particular software application, such as

those applications described above. Such encryption and decryption is

optionally performed by a separate encryption module (not shown), while a

connection is provided between software interface layer 18 and the network

(not shown) through a socket module (also not shown). Thus, the operation of

software interface layer 18 is preferably transparent to user computer 12 and to

the software applications operated by user computer 12.

Optionally and preferably, each software application operated by user

computer 12 may also separately and independently encrypt the data without

interacting specifically with software interface layer 18. For example, as shown

in Figure 2, Web browser 20 may encrypt data according to the SSL (secure

socket layer) protocol, while e-mail software program 22 may encrypt data

according to PGP or another type of encryption protocol. Either type of

encryption may be performed separately and independently, and without

reference to software interface layer 18. Furthermore, software interface layer

18 may further encrypt such encrypted data, again without reference to Web browser 20 or e-mail software program 22. Thus, software interface layer 18

preferably operates in a substantially completely transparent and independent

manner.

Figure 3 shows a schematic block diagram of an exemplary

implementation of the software interface layer of the present invention with the

Windows™ operating system architecture. However, it is understood that this is

for the purposes of description only and without any intention of being limiting,

as the software interface layer of the present invention can optionally and

preferably be implemented on many different types operating systems.

Examples of such operating systems include, but are not limited to, the various

Windows™ platforms (95, 98, 2000. NT), through the miscellaneous UNIX

variants, as well as the Macintosh™ O/S.

Although the socket implementation is different in each operating

system, the general structure is, in all cases, derived from the Berkeley socket

API, introduced in BSD 4.3. When two entities wish to exchange information

and communicate, they do so by establishing a socket. A socket is a virtual

"pipe" between the two entities, with one end connected to the connection

initiator, and the other end to the target. Once the socket is established, data

transfer is as easy as pushing data down one end of the socket, and reading the

data as it emerges on the other end of the socket. This model is readily apparent

(but not limited to) TCP based communications. For the sake of clarity, the

model described herein uses socket conventions, and primarily addresses TCP and UDP based connections. However, the same methodology may be applied

to IPX SPX, NetBEUI, AppleTalk, or any communication protocol.

The Berkeley socket API was ported into the Windows™ operating

system platform, with appropriate modification, and is known as "Winsock".

Since then, a major revision has taken place, and the current standard, which

will be discussed in this document in more detail, is WinSock2.

A description of Winsock and Winsock2 is provided in the Winsock

Service Provider Interface (SPI) specification [1]. Figure 3 illustrates the

Winsock architecture as it is known in the background art.

The Winsock 2 architecture, as shown above, actually promotes

applications to interface at the sub-socket level. This architecture introduces the

concept of a "service provider", that is, an agent implementing the socket API

(application protocol interface). When an application calls an API call,

(WSAStartUp, WSASend, etc.), the Winsock layer processes the call, and calls

a corresponding service provider call (WSPStartUp, WSPSend, etc.,

respectively). The mapping is a complete and well-documented one. In this

manner, multiple vendors may provide implementation for the Winsock API.

As shown, a WinSock software application 30 which is able to

communicate according to the WinSock API, communicates with a WinSock

DLL (dynamic linked library) 32. WinSock DLL 32 is divided into two

portions, for providing transport functions and name space functions

respectively. A transport service provider is responsible for the exchange of

data, or transport functions, between two network elements on a network. A name space provider is responsible for name space functions, which provide for

translation between canonical (word or symbolic) names and actual network

addresses, which are typically numerical IP addresses. The name space

provider generally uses the transport service provider to perform the resolution

of the canonical names to IP addresses. The name space provider also

translates network addresses, such as IP addresses, to canonical (word or

symbolic) addresses. The name space provider also translates IP addresses into

hardware MAC addresses. WinSock DLL 32 provides both sets of functions in

these two portions. WinSock software application 30 is therefore able to

invoke a transport service provider 34 or a name space service provider 36

through WinSock DLL 32.

Winsock 2 also supports layered service providers (2.4.1.1). Layered

service providers implement the high level communications functions, but fall

back on a lower level provider for the actual data exchange. As Figure 4 shows,

each transport service provider 34 may rely upon a layered service provider 38

in a stacked protocol chain, provided that the chain ends with a BASE protocol

provider 40, to perform the actual data communication. BASE protocol

provider 40 interacts with WinSock DLL 32 and with a physical transport

provider, such as a transport driver interface specification (described in greater

detail below with regard to Figure 5A), a network driver interface specification

(described in greater detail below in Figure 5B). WinSock DLL 32 is

responsible for the centralized management of network services, including

different types of transport providers, as described in greater detail below. The exact technical details for registering a service provider with the

Winsock layer are not discussed here, as they are well documented in the

abovementioned specification [1], explicitly incorporated by reference as if set

out in full herein.

Figure 5 A shows a schematic block diagram of the transport driver

interface architecture according to the background art. As shown, BASE

protocol provider 40 interacts with a plurality of different transport providers

34 for different types of network protocols, such as AppleTalk™, NetBT,

TCP/IP, and so forth. Each transport provider 34 in turn interacts with one of a

plurality of TDI (transport driver interface) clients 50 through a TDI interface

52. The plurality of TDI clients 50 include a socket emulator, a NetBIOS

emulator, and so forth. Each TDI client 50 communicates with a socket

application 54 through a socket interface 56 for the socket emulator, or else

with a NetBIOS application 58 through a NetBIOS interface 60 for the

NetBIOS emulator.

According to an alternative embodiment of the present invention, rather

than implementing a layered service provider structure as shown in Figure 4,

the present invention could instead be implemented through the network driver

interface specification, as shown in Figure 5B. According to such a

specification, the data would be intercepted and manipulated at a lower layer of

the OSI model than for the implementation of Figure 4. The layered service

provider implementation handles the data at the "presentation layer", or layer 6 of the OSI model. By contrast, the network driver interface implementation

would handle the data at the raw data level, or layer 2 of the OSI model.

As shown in Figure 5B, which is a schematic block diagram of the

network driver interface architecture according to the background art, a

hardware network connection device 64 interacts with a NDIS interface 66,

which includes a NDIS miniport 68 in communication with a native media type

interface 70. Native media type interface 70 is in turn in communication with

an NDIS intermediate 72 and a LAN media type interface 74. NDIS interface

66 communicates through TDI interface 52 to a plurality of components at the

kernel mode side. These components include a NetBIOS emulator 78 and a

socket emulator 80, each of which features a kernel-mode driver; and a kernel-

mode TDI client 82.

On the user mode side, each component communicates with a

corresponding component from the kernel mode side. The user mode side

includes a corresponding NetBIOS emulator 86 and a socket emulator 88, each

of which features a user-mode DLL (dynamic linked library). Both NetBIOS

emulator 86 and socket emulator 88 communicate with a user-mode client 84.

According to a particularly preferred embodiment of the present

invention, both types of implementations are combined, and the layered service

provider implementation is preferably used for management, while the network

driver interface implementation is preferably used for traffic control. Also in

this implementation, WinSock DLL 32 manages the network services,

including the different types of service providers. Figure 6 describes the initiation of a socket connection with the software

interface layer of the present invention. As shown in greater detail below, the

software interface layer is preferably installed below the socket layer. When a

software application issues a system call to create a socket, the software

interface layer of the present invention intercepts that call, and returns a

different descriptor in place of the original socket. Any data sent by the

software application through the returned descriptor is passed to the software

interface layer of the present invention rather than being sent directly to the

intended destination. The software interface layer may therefore manipulate the

data, encrypt the data and even reroute the data.

The software interface layer of the present invention also optionally and

preferably listens to the network. Upon the arrival of any encrypted data, the

software interface layer intercepts the data, decrypts the data, and passes the

decrypted data to the relevant software application according to the socket

descriptor returned from the socket () system call. In the case of applications

which perform the bind () and listen () functions for connections, the software

interface layer transparently integrates these different functions, by collapsing

all the incoming connections to one well-known port. Any encrypted

connection requests thus arrive, tunneled, at the software interface layer WKP

(well known port). These encrypted requests are decrypted by the associated

software layer, and passed on to the software applications which bound the

original socket. Unencrypted connection requests arrive at the original port, and

are immediately passed on to the relevant application. Thus, the receiving software application does not need to know whether the incoming connections

are encrypted.

A well known port is a port number which is assigned by IANA (Internet

Assigned Number Authority), which is responsible for the management and

assignment of system port numbers to appropriate applications on the

international level. For example, the well-known port for the TELNET

application is 23. The well-known port assignment is reserved for such an

application on any standard, Internet-compliant system.

The advantage of using a well-known port for all types of data by the

software interface layer of the present invention is that the original type of

communication is masked, since all different types of data are routed to a single

well-known port for the software application of the present invention.

Therefore, unauthorized users cannot determine the content type by knowing

the port numbers involved, since all different types of content are transported

through a data connection to the same port.

As shown in Figure 6, when an application issues a socket () creation

call, the software interface layer of the present invention intercepts this creation

call (step 1). As the software interface layer intercepts the connect () system

call, it does not create an immediate socket to the target. Rather, the software

interface layer blocks the call, and first checks if anonymity is required (step 2).

If so, the software interface layer contacts a proxy through a secure

communication channel (step 3a(l)). The proxy then performs the connection

to the actual endpoint (step 3a(2)). Alternatively, if anonymity is not required, the software interface layer

attempts to contact the actual target, but instead of addressing the end service

(port), it attempts contact with the software interface layer well-known port. As

previously described, this has the advantage of obscuring the type of data which

is being transmitted.

In either case, upon the formation of a successful connection, the

software interface layer returns a socket descriptor to the caller (step 4). While

seemingly a standard socket descriptor, the returned value actually serves the

software interface layer as a handle for an entry in an array of actual sockets.

Since subsequent API calls always include this returned value, the software

interface layer can handle multiple connections.

If the socket is not connected, the software interface layer is inactive.

Activation of that socket, for example through a connect () call or a similar

system call, also activates the software interface layer.

If the secure connection fails, for example because the endpoint does not

feature the software interface layer of the present invention, the socket is still

returned, but only as a standard, connected socket. The software interface layer

cannot intervene and apply any encryption, since obviously the target endpoint

cannot support such encryption. Communication through this socket then

proceeds normally, as if the software interface layer is not present.

Assuming that the secure connection is created, then the software

interface layer answers the connection request and a socket connection is

created. The procedure for actual communication is shown in Figure 7. In step 1, the socket connection is established with the software interface layer of the

present invention. If the connection is refused, the software interface layer

performs an unencrypted connection (step 2a). In step 2b, if the secure

connection is formed, then the software interface layer determines whether the

two parties have previously communicated. It should be noted that the two

parties are described herein as being a "client" and a "server" for the purposes

of description only and without any intention of being limiting. Furthermore,

unless otherwise stated, the term "software application layer" refers to the

software application layer of the client.

If the two parties have not previously communicated, the software

interface layer establishes a connection between the client and the server by the

"standard" method of public key exchange (step 3 a). Once the two parties

communicate, a unique session ID is generated. Any subsequent connections

initiated by one party to the other may use the previous session ID and

encryption key in order to continue the communication (step 3b). Thus, if one

party is not authentic, then the inauthentic party cannot know the encryption

key and so cannot masquerade as an authentic party for the purposes of

communication.

This method enables a form of protection against the "Man in the

Middle" attack, which is a serious vulnerability in public/private encryption

methods. An inauthentic party would have to listen to and successfully decrypt

all the connections between the two endpoints in order to successfully assume

the identity of either of the parties. Since the encryption scheme changes in mid-session as well, if the inauthentic party fails to decrypt even a single

packet, the inauthentic party would not be able to jeopardize the secure session

between the two authentic parties.

In step 4, the software interface layer determines whether the server is

the final endpoint for the communication or a proxy. If the server is a proxy,

then in step 5a, the client requests the server to establish a connection with the

actual endpoint. In step 6a, the software interface layer determines whether the

request is successful. If the request is successful, then in step 7a, the software

interface layer returns a socket descriptor. Otherwise, in step 7b, the software

interface layer returns an error message.

Turning now to the other branch of the method, in step 5b, if the server

is the final endpoint for the communication, then the client and server establish

a secure communication session with a unique ID.

One very important point to emphasize is that the caller application is, at

this and any other point, totally unaware of how the socket descriptor is in fact

being handled. Indeed, the management of the socket by the software interface

layer is completely transparent to the caller application. Furthermore, the

socket may actually be connected to an endpoint other than the intended target.

The caller application may now proceed to handle the socket descriptor

normally, by performing IOCTL calls, send () calls and receive () calls, as

shown in greater detail with regard to Figures 8A and 8B below. The software

interface layer handles those calls, and manipulates the data prior to its

transmission or reception. Figure 8A shows an exemplary method for handling a send() call

according to the present invention. In step 1, the software interface layer

intercepts the send () call. In step 2, the software interface layer reads the data

buffer as the data is passed to the send () call. In step 3, the software interface

layer causes the data to become encrypted. Alternatively and preferably, the

encryption is performed by a separate software module in communication with

the software interface layer, in order to increase the modularity of the present

invention. In step 4, the actual send () call is performed through the

corresponding socket for the software interface layer of the present invention.

Similarly, in Figure 8B, an exemplary method is shown for intercepting

and handling a receive system call. In step 1, the recv() call is intercepted by

the software interface layer. In step 2, the software interface layer receives the

incoming data through the corresponding software interface layer socket. In

step 3, the software interface layer decrypts the data, although alternatively and

preferably, as previously described, the decryption process may be handled by a

separate module. In step 4, the decrypted data is passed to the calling

application through an attached data buffer.

The exact implementation of communication between client and server

could easily be determined by one of ordinary skill in the art.

As noted above, preferably the software interface layer has a modular

architecture. Since encryption has proven itself to be an ever-changing field,

with ever increasing key sizes and new algorithms, the present invention

preferably does not require only one algorithm. Rather, the present invention preferably treats the encryption as a module which is more preferably

interchangeable with substantially any other type of encryption. The exact

method of encryption is irrelevant to the calling applications.

Examples of different encryption algorithms which may be used with the

present invention include, but are not limited to, RSA, Blowfish, and TwoFish,

all of which are in the public domain. Each such algorithm may be included in

the separate encryption module, such that the plaintext is received by the

encryption module, encrypted and then transmitted as ciphertext. Thus, the

encryption module can easily be changed, since if, for example, a new

algorithm is released, or an existing algorithm is changed (for example with a

key-size modification), the relevant algorithmic module would be replaced, but

nothing else would be modified.

According to a preferred embodiment of the present invention, multiple

different types of encryption are included. Preferably, during a single session

with the software interface layer of the present invention, the type of encryption

algorithm changes periodically, on a random basis. Such a periodic change

reduces or eliminates the probability of a successful "replay" or "cut&paste"

attack, in which an eavesdropper can try and assume the identity of one of the

parties involved by re-transmitting encrypted text which was previously

captured. For example, in the replay attack, the eavesdropper "replays"

previously captured encrypted text. If the encryption key has not been changed

in the interim, the encrypted text is decrypted back into a valid message, and

may be mistaken for one. Optionally and preferably, the encryption method and/or key is changed

at least once per session, more preferably in mid-session. The change of

encryption method/key may be as often as once per packet, or even in mid

packet. Such multiple changes forces the eavesdropper to successfully decrypt

every packet of data transmitted between the two parties, without which any

cryptanalysis under this system would be futile.

The flexibility and ease of use of the software interface layer of the

present invention are suitable for both the private, dial-up Internet user and the

corporation in need of an effective, low-cost, dynamic NPN (virtual private

network). For the latter implementation, privacy is guaranteed by encryption of

the data before transmission between two nodes on the network, whether on the

Internet or on a LAN (local area network). Furthermore, this alternate VPN

mechanism is compatible with other, existing mechanisms and protocols, such

as PPTP (Point-to-Point Tunneling Protocol), which allows a point-to-point

connection to be tunneled in a network environment, hence emulating a NPN

for a VPN-like connection.

For the private, dial-up user, a session-oriented NPN-like connection to

the desired Internet and/or other networking services is provided. The software

layer of the present invention provides a standardized system for data

encryption at a lower level, for all operating systems, regardless of vendor or

architecture, and with full, system-wide transparency. Furthermore, since the present invention complies with the OSI networking model, the present

invention is also compatible with the Internet itself.

The software interface of the present invention provides a standard,

friendly yet advanced interface to the configuration of the encryption modules,

while simultaneously hiding all encryption-related issues both from the user,

and from the operating system and applications. These encryption-related issues

include but are not limited to, key exchange protocols, ciphering algorithms,

and so forth.

According to another implementation of the present invention, a series of

software interface layers connected in a system according to the present

invention could be used to provide an infrastructure for secure channels on the

Internet. These secure channels could feature a virtual "hub" of interconnected,

secure "tunnel-hosts" (proxies), thereby enabling clients to join at any point on

the hub, and thus mask all connections, supplying clients with both security and

anonymity.

According to another preferred implementation of the present invention,

in addition to encryption, the software interface layer optionally and preferably

support data compression. Compression not only serves as a defense against

some forms of cryptanalysis (especially those which consider known

plaintexts), but also greatly enhances the connection quality.

The basic encryption mechanism of the software layer of the present

invention supports the use of POTP (Polymorph One Time Pad), in which the

same key is not used to encrypt data twice. Inherently, this method works only with password associated encryption, and not with other types of encryption,

such as hash function ciphering methods. POTP is, however, a powerful tool,

making cryptanalysis virtually, or computationally impossible. POTP is

preferably integrated into the software interface layer in the form of an

encryption module. It should be noted that POTP is not a new encryption

algorithm, but rather is a way of enhancing existing algorithms.

According to yet another preferred implementation of the present

invention, since the software interface layer operates with a client-server

architecture, a server according to the present invention can optionally be

designed to detach and keep sessions alive upon client request or hang-up.

Also, such a server can optionally be used as a mediator between untrusting or

unfamiliar parties, as per the proxy mediator function, described above.

It will be appreciated that the above descriptions are intended only to

serve as examples, and that many other embodiments are possible within the

spirit and the scope of the present invention.

Appendix - References

[1] WinSock2 Service Provider Interface Document - publicly available from

the Internet site: ftp://ftp.microsoft.com/pub/bussys/winsock2. The version

referenced is 2.2 (WSSPI22.DOC)

[2] WinSock2 Application Programming Interface Document - publicly

available from the Internet site: ftp://ftp.microsoft.com/pub/bussys/winsock2.

The version referenced is (WSAPI.DOC)

[3] Applied Cryptography, 2^nd Edition, By Bruce Schneier, 1996

Claims

1. A system for secure transmission of data on a network, the system

comprising:

(a) a first computer connected to the network for transmitting the data

on the network;

(b) a first interface layer being operated by said first computer and for

being located between said first computer and the network, such

that all data transmitted from said first computer passes through

said first interface layer before being transmitted on the network,

and for encrypting said data to form encrypted data;

(c) a second computer connected to the network for receiving said

encrypted data on the network; and

(d) a second interface layer being operated by said second computer

and for being located between said second computer and the

network, such that all data received from the network passes

through said second interface layer before being received by said

second computer, and for decrypting said encrypted data to form

decrypted data, said decrypted data being passed to said second

computer.

2. The system of claim 1, wherein data is transmitted on the network

according to the seven layer OSI model, such that said data is exchanged between the network and said first and said second interface layers at a network

layer of said model.

3. The system of claim 1, wherein a transmitting software

application operated by said first computer connects to said second computer

through a first socket, said first socket being implemented by said first interface

layer, such that a receiving software application receives said encrypted data

through a second socket, said second socket being implemented by said second

interface layer, such that all data transmitted by said transmitting software

application and received by said receiving software application passes through

said first interface layer and said second interface layer.

5. The system of claim 4, wherein said first interface layer listens on

said first socket for data being sent by said transmitting software application

through said first computer, while said second interface layer listens on said

second socket for data being received by said second computer for said

receiving software application, such that operation of said first interface layer

and said second interface layer is transparent to said first computer and to said

second computer, as well as to said transmitting software application and said

receiving software application.

6. The system of claim 5, wherein each of said first socket and said

second socket mctudes a standard port for receiving data, said standard port being directly connected to each of said first interface layer and of said second

interface layer.

7. The system of claim 1, further comprising:

(e) an encryption module for each of said first and said second

interface layers, for encrypting data prior to transmission on the

network, and for decrypting data received through the network.

8. The system of claim 7, wherein a transmitting software

application operated by said first computer further comprises an application-

specific encryption module, such that said transmitting software application

first performs an application-specific encryption on said data before said first

interface layer encrypts said data for transmission on the network.

9. The system of claim 7, further comprising:

(f) a final destination computer; and

(g) a final destination interface layer being operated by said final

destination computer, such that said second computer in

combination with said second interface layer forms a proxy server

for mediating between said first computer and said first interface

layer, and said final destination computer and said final

destination interface layer.

10. The system of claim 7, wherein said encryption module

additionally features POTP (Polymorph One Time Pad), such that a key for

encrypting said encrypted data is used only once.

11. The system of claim 7, wherein said first interface layer and said

second interface layer communicate in a session for data transmission and

wherein said encryption module features a plurality of encryption mechanisms,

each of said plurality of encryption mechanisms featuring a key, such that at

least one of said encryption mechanism and said key is changed at least once

during said session.

12. The system of claim 1, wherein the network is the Internet.

13. The system of claim 1 , wherein the network is an intranet.

14. A method for secure transmission of data from a first computer to

a second computer on a network, the method comprising the steps of:

(a) requesting a connection for data transmission by a first software

application operated by the first computer to a second software

application operated by the second computer through the network; (b) generally encrypting data received from the first software

application before transmission on the network to form encrypted

data, such that the data is encrypted at a network layer;

(c) transmitting said encrypted data on the network;

(d) receiving said encrypted data by the second computer;

(e) generally decrypting said encrypted data to form decrypted data at

said network layer; and

(f) passing said decrypted data to said second software application.

15. The method of claim 14, wherein steps (b) and (e) are transparent

to said first software application and to said second software application.

16. The method of claim 14, wherein step (b) is performed such that

said encrypted data masks a data type of said first software application, such

that said data type cannot be determined from said encrypted data.

17. The method of claim 14, wherein step (b) further comprises the

step of performing application-specific encryption by said first software

application before the step of general encryption is performed, while step (f)

further comprises the step of performing application-specific decryption after

the step of general decryption is performed.

18. The method of claim 14, wherein step (c) is performed through a

secure proxy, such that step (c) further comprises the steps of:

(i) contacting said secure proxy by said first computer;

(ii) contacting said second computer by said secure proxy; and

(iii) establishing a connection between said first computer and said

second computer by said secure proxy.

19. The method of claim 18, wherein step (iii) is performed such that

said first computer and said second computer communicate directly.

20. The method of claim 18, wherein step (iii) is performed such that

said first computer and said second computer communicate only through said

secure proxy server, such that said first computer and said second computer are

anonymous.

21. The method of claim 18, wherein steps (i)-(iϋ) are performed only

to establish a first session between said first computer and said second

computer, such that subsequent sessions are established directly between said

first computer and said second computer.

22. A software interface layer for encrypting data transmitted from a

computer and for decrypting data received by the computer, the software

interface layer comprising: (a) an encryption module for encrypting and decrypting the data; and

(b) a socket- forming module for forming a socket between a standard

port and any software application operated by the computer, such

that said encrypted data is transmitted through said socket and

said decrypted data is received by said software application.