WO2019138399A1

WO2019138399A1 - A method and a computer program for exchanging secured peer-to-peer communications

Info

Publication number: WO2019138399A1
Application number: PCT/IL2018/050883
Authority: WO
Inventors: Eran ASANTE-ASARE; Karol ARAKELIAN; Ofir HUBER
Original assignee: Copa Media Ltd.
Priority date: 2018-01-15
Filing date: 2018-08-09
Publication date: 2019-07-18

Abstract

A method and a computer program implementing that method are provided, for enabling transfer of peer-to-peer secured data from a first user to a second user along a communication path established by a server configured to communicate with each of said two users by using their respective IP addresses and/or socket IDs. The method is characterized in that the server is further configured to generate tunnels for streaming data directly between the users, and wherein the server is not exposed to data being transferred between the users.

Description

A METHOD AND A COMPUTER PROGRAM FOR EXCHANGING SECURED PEER-TO-

PEER COMMUNICATIONS

TECHNICAL FIELD

The present disclosure generally relates to the field of peer- to-peer communication systems. More particularly, the present disclosure relates to establishing reliable connections between peers in a peer-to-peer networking environment.

BACKGROUND

Sending and receiving sensitive information and files in internal and external communications are part of ordinary business life. However, as simple as it may sound, there are no easy ways of doing that without having the file passing through a third- party server, such as the one hosting the company' s email or Google Drive, etc. Unfortunately, there are quite a few disadvantages associated with these servers are:

a) Limited in their capacities, making transfer of large files a rather complicated task;

b) Vulnerable to cyber-attacks as well as to simple snooping by the service provider for various purposes, such as targeted marketing;

c) Slow functioning, as single servers serve hundreds, and sometimes thousands, of requests simultaneously; and d) Complicated implementation, as they may require setting up by professional IT people.

Furthermore, every company needs to transfer information, whether internally or to external recipients. In many cases, this information is rather sensitive and quite often it is comprised in very large files. In most cases email attachments are used for transferring such files (e.g. confidential files), yet, there are some major problems associated with such activities, some of which are the following:

a) Security - emails are the first to be targeted in a cyberattack. In addition, hackers are now attempting to reach companies' by targeting their cloud service providers, which transfer data along a company's digital supply chain.

b) Privacy - although companies like to think that their information is kept away from prying eyes, when they use 3rd party email providers or other cloud services for file transferal/storage, they expose themselves to the service providers data probes. Furthermore, most service providers are known to provide data to third parties (or use that data for their own purposes) which is then used for advertising purposes, using details associated with their users. Thus, mail addresses of users utilizing these services are being exposed for sending to them spam mail, junk mail, phishing, hacking etc.

c) Size limitations - most emails providers limit the size of files to several megabytes of data, e.g. up to 25 Megabytes in the case of Gmail. Yet, many files today, especially those involving graphical data, are much larger than that. d) Access control - Once a file has been transferred as an email attachment, it is no longer in the control of the sender. The recipient can forward it to anyone, even without the sender awareness, thus potentially exposing confidential information .

More sophisticated companies may elect to use managed services - web drives such as Dropbox or cloud-based file transfer services such as WeTransfer. However, these services too, suffer from major security drawbacks, such as:

(i) A Central location - all files are kept on the service's server which is susceptible to cyber-attacks and phishing attempts and can be infected by malware which will affect all the rest of the supply-chain.

(11) End-user vulnerability - even when the senders attempt to maintain all the security protocols, still they have no control over their files once they reach the target recipient. The recipient may save the file on a vulnerable computer or send it to someone else without the originator's permission.

(ill) Inherent privacy gaps - Even companies that maintain IT departments or outsourced managed file transfer services, still suffer from the exact same problems.

Traditional file transfer solutions

More technically savvy companies may set up an FTP server. Small businesses may also opt to share files using simple collaboration platforms such as Dropbox. However, these solutions suffer from inherent cyber-vulnerabilities as well as from size limitations. In addition, file senders lose all control over the files once they have been shared.

MFT and EFSS solutions

Managed File Transfer ("MFT") solutions and Enterprise File Synchronization and Sharing ("EFSS") for enterprises are offered by companies such as IBM, Microsoft, OpenText, and GlobalScape, and they are rather complicated solutions. These solutions can provide high-grade cyber-security while transferring the files, but often they use a dedicated cloud-server to store all information, which in turn creates a central-point of vulnerability. MFT solutions are also technically challenging and require an inhouse IT department to manage them. Moreover, they are often sold at very high prices . Individuals and particularly businesses require an easy to use, secure, private, and inexpensive way to transfer large files while still maintaining control over the data transfer and the ability to audit usage.

US 7127613 for example, describes a system and a method for providing secure exchange of messages between peers in peer groups. The publication relates to secured sessions to be held between peers in the peer-to-peer network, and secured group sessions among a plurality of peers. The disclosure relies on generating a public key by a first peer which is then sent to a second peer. The second peer generates a session key from the public key. The second peer sends a secured session key to the first peer, and messages and/or other data exchanged between the two peers may be encrypted and decrypted by using that session key.

However, there are still quite a few security problems associated with such a solution, problems which the present disclosure seeks to overcome as part of the solution described hereinbelow .

The present invention seeks to provide a solution to the above drawbacks .

SUMMARY

The disclosure may be summarized by referring to the appended claims .

It is an object of the present disclosure to provide a system and a method that enable a secured safe end-to-end private file transferring service with no size limitation.

It is another object of the present disclosure to provide a system and a method that enable obtaining control over the end- to-end private file transferring service and to allow determining which user is permitted to obtain access to one's sensitive media and documents, when, and for how long that user (the recipient) will be able to read or edit one's files.

It is still another object of the present disclosure to provide a system and a method wherein the server acts as an identifying element for a point-to-point communication between senders to recipients but has no access to hold or store the data being exchanged.

It is yet another object of the present disclosure to provide a system and a method that enable encrypting files before they are being transferred (i.e. before leaving the sender's computer) so that no third-parties can view the files, and only the recipient is able to decrypt them.

It is another object of the present disclosure to provide a system and a method that enable a secured end-to-end private file transferring service in which the transferred files are not stored in a cloud or at a server.

It is another object of the present disclosure to provide a system and a method that enable a relative simpler solution than the complicated FTP solutions or other that are similar to them, or on the other hand as expensive and dedicated only for biggest organizations (like virtual vaults) .

Other objects of the present disclosure will become apparent from the following description.

According to a first embodiment, there is provided a method for enabling transfer of peer-to-peer secured data from a first user to a second user along a communication path established by a server which is configured to communicate with each of the two users by using their respective IP addresses or socket IDs, and wherein the method is characterized in that the server is further configured to generate tunnels for streaming data directly between the users, and wherein the server is not exposed to data being transferred between the two users. The term "user" or "peer" as used herein throughout the specification and claims, are each used to denote either a person working on a computing platform such as a computer terminal, or a device being a computing platform that is capable of communicating with other devices such as servers, user terminals, etc.

According to another embodiment, the method provided comprising the steps:

(i) receiving newly generated security keys by the first user and the second user pursuant to their login to an application configured to enable provisioning of peer-to-peer communications;

(ii) initiating by the first user a request for establishing a transfer session by uploading data that comprises a security key associated with the second user or comprises an identification of the second user, provided the identification of the second user together with other parameters associated with the first user, are included in a pre-defined list of authorized users;

(iii) checking by the server the security key associated with the second user, and wherein if the server is capable of retrieving required information associated with the second user, the server is configured to create a token of a new approval object, and to add IDs of the first user and the second user to a database adapted to store data associated with users of the application;

(iv) generating by said server a request attached to the approval object and forwarding it to the second user;

(v) sending by said first user to the second user a security key, or an identification of said first user, provided the identification of the first user together with other parameters associated with the second user are included in a pre-defined list of authorized users;

(vi) checking by the server the token of the approval object, wherein in case the server is capable of successfully retrieving required information associated with the first user, the server will update the approval object by adding that information thereto, without storing information that relates to the second user, and will change a value associated with a first parameter to a pre defined value (e.g. to the value "true") ;

(vii) sending by the server to both users the updated approval object token;

(viii) upon determining by the second user that the value of the first parameter is that pre-defined value, beginning to listen at the second user side for incoming requests;

(ix) upon determining by the first user that the value of the first parameter is the pre-defined value, retrieving by the first user information that relates to the second user (e.g. his IP address and port identification or his socket ID) ; and

(x) Once both users have acquired all necessary details for carrying out the data transfer process, beginning a data transfer process .

By yet another embodiment, step (ii) further comprising confirming email addresses and/or usernames associated with the second user.

In accordance with another embodiment, the method further comprises a step of:

(xi) upon completing the data transfer process, discarding the approval object, deleting the approval token of the first user from a list of requests to be displayed at the second user terminal (e.g. when connection is carried out via socket streaming) . Optionally, at least one of the first and second users will cease listening to the designated port for the data transfer process (e.g. when connection is carried out via users' ports) .

According to yet another embodiment, the first user controls the data that had already been transferred to the second user while carrying out the data transfer process. In addition, the control comprises optionally associating the data transferred with a pre- determined deletion time, at which time the transferred data shall be removed from the second user system, without leaving any copy thereof that can be accessed from the second user system. By another option, the control comprises providing the first user with an option to cancel the transfer of data, after the path generated for the data transfer has already been established.

In accordance with another embodiment, the method further comprising a step of checking by the server whether the first user and the second user are located within a single local network, and if in the affirmative, carrying out the data transfer process within that single local network.

By yet another embodiment, the data to be transferred in the data transfer process, is encrypted by the first user without providing the server with any means to decrypt the encrypted data.

In accordance with another embodiment, the method further comprises a step whereby the second user generates at his own local system a token, and wherein that token is transferred to the first user, and upon its receipt by the first user's application, the application verifies that the token is a legitimate token to be used in the system and preferably that it has not been tempered. Only after such a verification is achieved, the data stream may be transferred. Optionally, if such a verification is not obtained, the request may be blocked. By another option of this embodiment, the token is conveyed from the first user to the second user once the transfer process has begun, possibly by attaching the token to data being transferred.

According to still another embodiment, the first user whose identification is stored in a database comprised at the server, is capable of initiating the establishment of the communication path for the transfer of peer-to-peer secured data to a second user whose identification is not currently stored in a database comprised in the server. By yet another embodiment the first user whose identification is stored in a database comprised in said server, is capable of initiating the establishment of the communication path for the exchange of peer-to-peer secured data with a second user whose identification is not currently stored in a database comprised in the server.

In accordance with another embodiment, the method provided comprising a step of generating random encryption keys associated with the first user, for use in encrypting and decrypting files located at a pre-defined folder of the first user and wherein upon adding a new file to that pre-defined folder, automatically encrypting the newly added file.

According to another embodiment, the transfer of peer-to-peer secured data from/to the first user to/from the second user is carried out automatically in response to adding a new file to a pre-defined folder located at the respective user's device.

According to another aspect of the disclosure, there is provided one or more non-transitory computer readable medium storing a computer program for performing a set of instructions to be executed by a plurality of computer processors, the computer program is adapted to perform a method for enabling transfer of peer-to-peer secured data from a first user to a second user, which comprises the steps of:

(i) generating security keys by a first user and by a second user, pursuant to their respective login to the computer program;

(ii) initiating by the first user a request for establishing a transfer session by uploading data that comprises a security key associated with the second user or comprises an identification of the second user, provided that the identification of the second user together with other parameters associated with the first user, are included in a pre-defined list of authorized users; (iii) checking by a server the security key associated with the second user, and wherein if the server is capable of retrieving required information associated with that second user, the server generates a token of a new approval object, and adds IDs of the first user and the second user to a database adapted to store data associated with users of the computer program (i.e. the application) ;

(iv) generating by the server a request and attaching the request to the approval object which is then forwarded to the second user;

(v) sending by the first user to the second user a security key, or an identification of the first user, provided the identification of the first user together with other parameters associated with the second user, are included in a pre-defined list of authorized users;

(vi) checking by the server the token of the approval object, wherein in case the server is capable of successfully retrieving required information associated with the first user, the server will update the approval object by add that information thereto, without storing information that relates to the second user, and will change a value associated with a first parameter to a pre defined value (e.g. to the value "true") ;

(vii) sending by the server to both users the updated approval object token;

(ix) upon determining by the first user that the value of the first parameter is that pre-defined value, retrieving by the first user information that relates to the second user (e.g. his IP address and port identification or his socket ID) ; and (x) once both users have acquired all necessary details for carrying out the data transfer process, beginning a data transfer process .

In accordance with another embodiment, the method further comprises a step of:

(xi) upon completing the data transfer process, discarding the approval object, deleting the approval token of the first user from a list of requests to be displayed at the second user terminal .

According to yet another embodiment, the computer program enables the first user to control data that had already been transferred to the second user while implementing the data transfer process .

By yet another embodiment, the data to be transferred in the data transfer process, is encrypted by the first user without providing the server with any means to decrypt the encrypted data. In accordance with another embodiment, the method further comprises a step whereby the second user generates at his own local system a token, and wherein that token is transferred to the first user, and upon its receipt by the first user's application, the application verify that the token is a legitimate token to be used in the system and preferably verifying that it has not been tempered, and only after achieving that verification, transferring the data stream. According to another aspect, there is provided a set comprising a plurality of non-transitory computer readable medium storing a computer program for performing a set of instructions to be executed by a plurality of computer processors, the computer program is adapted to perform a method for enabling transfer of peer-to-peer secured data from a first user to a second user as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate several embodiments of the disclosure and, together with the description, serve to explain the principles of the embodiments disclosed herein .

FIG. 1 illustrates a flow chart of a method exemplifying an embodiment construed in accordance with the present invention; and FIG. 2 illustrates an example of a system construed in accordance with an embodiment of present invention, for retrieving instructions to be used when establishing the peer-to-peer secured data transfer.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

Some of the specific details and values in the following detailed description refer to certain examples of the disclosure. However, this description is provided only by way of example and is not intended to limit the scope of the invention in any way. As will be appreciated by those skilled in the art, the claimed method and system may be implemented by using other methods that are known in the art per se. In addition, the described embodiments comprise different steps, not all of which are required in all embodiments of the invention. The scope of the invention can be summarized by referring to the appended claims. Embodiments of the present invention disclose a system, referred to herein as "COPA, " which provides a secured end-to-end private file transferring service having no size limitation. First and foremost, the system offers a complete control over who gets to review one's most sensitive media and documents, when, and for how long the recipient will be able to read or edit your files.

Other characteristics of the system, whether optional or not, include among others:

_• A server that acts as an identifying entity for enabling a point- to-point communication to be exchanged between senders and respective recipients, which has no access to the data exchanged, i.e. the server does not hold or store the data exchanged.

Files that are sent using the present system may be encrypted prior to their transfer and are not stored at any cloud or any of the system's servers. Files are encrypted before leaving the sender's computer so that third-parties cannot review the files, but only the intended recipient who is capable of decrypting them. The system provides an additional secured layer by enabling users to set and define their own personal encryption/decryption passwords. The self-encryption/decryption ensures that only the intended user may access the information in the application. The system has no access to the selected passwords, a feature that provides a further layer of security.

Users are able to customize their privacy control and ensure full anonymous mode while using the COPA system. The system allows users to control and determine who can review their most sensitive media and documents, for reading/editing the files.

Files are available and accessible exclusively (view-only) in COPA' S Explorer/Viewer , with a self-destruct timer, which grants a precise time-framed view.

Users may be prevented from copying files transferred via the COPA system to other directories, or having them duplicated, including saving files' copies, forwarding the files, or printing the files by using the "print screen" function.

In contradistinction to typical prior art solutions which first upload the file that needs to be transferred to the cloud, where it is held unprotected until the recipient downloads it, and typically, as the files are stored thereat, they remain in the cloud even after the recipient has downloaded the file. The COPA system on the other hand, provided by the present invention, transfers the files directly from one user (the sender) to the second user (the recipient) .

Mail services, cloud services, websites for file transferal - all hold a copy of the sensitive information, thereby increasing the risk of exposure of the files that are stored at the intermediate's server.

These prior art solutions do not offer control on the recipients' environment - once the file is forwarded towards the recipient there is no control on privacy (on viewers, distribution, printing permission etc., and obviously any encryption applied to the file would be useless when a file remains in its open mode) .

Furthermore, most services provide data that relate to their users, to third parties (or use it for their own purposes) which need this data for advertising purposes. Mail addresses that are provided to such third parties are exposed and open to spam, junk- mail, phishing, hacking etc.

The use of the COPA server of the present invention is used to approach users' addresses and to generate tunnels for streaming data directly between authenticated users, and that server is not part of the data transfer process itself, so that the server is not exposed to data being transferred between the authenticated users .

In an embodiment of the invention, when implementing transfer between ports of the user or implementing transfer within a local network, the server is not part of the transfer process, and its only role in the process is to establish the connection between the peers. Consequently, even if the server fails, the transfer process will still continue irrespective of that failure.

According to another embodiment of the invention, users may utilize the system and the method provided herein in an anonymous mode. In other words, users may use the system by generating a one-time user object with a "security key" identification that enables him only to generate a connection with a COPA user, without having to identify himself to the system as a condition to have the peer to peer path established. The anonymity of the user is kept by completely deleting every reference to this unidentified user from the system, once the application at the anonymous user side has been logged off.

APPLICATION SERVER DATABASE

COPA' s application source code is preferably first encrypted, which makes it harder to review the source code. Furthermore, after the encryption of the source code, COPA may be compiled to a binary build, which makes it harder to reverse the code.

In the following example of a system as disclosed herein, the server is running using Linux Debian OS, secured with IP tables and strict regulation. This allows only certain ports to be accessible with Transport Layer Security (TLS\SSL) protocol. TLS\SSL provides a secure channel over an unsecured network in a client-server architecture, connecting an application with a server under TLS\SSL connection.

In the present example, COPA' s database runs on a Linux server with a restriction that only local connection is used. This feature prevents the database from being exposed to outside entities. Furthermore, the database preferably has a strict parameters validation system, for preventing the database from being exposed to untrusted data.

"LOGIN" SCREEN

The login screen appears when a user enters the application. A user who wishes to register to the COPA system, preferably enters his email address and a password, and is the allowed to log to COPA. A non-registered user may either continue their login process by accessing "create account link", followed by completing a registration procedure, or by accessing "Go Anonymous" option, which enables the user to log in as an anonymous user.

"HOME" SCREEN

Once the user has logged in to the COPA system, he may press the 'Choose Files' button thereby causing the opening of the File Upload Screen. 'Drag & Drop' area in that screen allows the user to drag folders or files to the screen and add them to the transfer request. The user may then press the 'COPA Profile' button, thereby causing the opening of the Profile Settings Screen. The 'COPA Transfers' Icon which appears in that screen, will display a number of new transfer requests if any such requests are available, or a warning sign, indicating old requests that have not yet been acted upon. Pressing this icon opens the 'COPA Transfers' screen. Similarly, the 'COPA Contacts' Notification Icon will display a number of new friend requests and\or requests confirmed by others if such exist. Pressing it will open the 'COPA Contacts Screen. Similarly, the 'COPA Viewer' Notification Icon will display a indications of new advanced files that are ready for display, if available. Pressing it will open the 'COPA Viewer' Screen. Optionally, the 'COPA Chat' Notification Icon will display a number of new messages ready for being displayed. Pressing it will open the 'COPA Chat Screen. "HOME ADVANCED OPTIONS" SCREEN

Every user receives a security key generated in combination with his/her email address and username, as the user himself had entered. Once a user has logged in to the COPA system, if the 'security key' is enabled, a newly generated password for each new session (a 'security key') will be displayed. If the 'self encryption' option is enabled, then once the user has logged in to the COPA system, the user will be asked to enter his 'self encryption' password in order to be able to encrypt/decrypt messages and advanced files.

"OPEN FILE" SCREEN

This screen appears according to the present invention when the user selects the 'Choose Files' option. The user may locate system files through using this dialog and option and then upload the selected files to the application transfer request.

"SEND FORM" SCREEN

This screen appears after the user has uploaded a file. The user is provided with an option to add further files by simply selecting the 'Add more files here' option or drag more files to the files information block. According to a first option (classic security), the user is able to insert the recipient's email, username or 'security key' depending on how the other side had chosen to be identified. The recipient's name may be added by the user's contact list (i.e. 'COPA Contact') and the user is able to add further recipients to the 'Request Summary' by inserting their relevant information in accordance with the above-described procedure .

A 'Transfer' button will initiate a request process while a 'cancel' button removes the files and the application returns to the 'Home Screen' . Obviously, the user may select a recipient's name from the 'Request Summary', in order to review their details (e.g. name, password) as well as to edit their details or even deleting recipients from the 'Request Summary' all together. Also, the user may remove a file from the "Files Information Block", in order to edit files that are included in the request.

"ADVANCED SECURITY FORM" SCREEN

This screen appears according to the present invention after the user has selected to apply the 'Advanced Security' method.

The user may review certain files information such as filename, file type etc. However, once the 'Advanced Security' option has been selected, the user is provided with a menu that can be used in selecting duration options, i.e. the desired period time after which the file will be deleted ( 'File Lifespan' ) before the recipient is added to the 'Request Summary' .

"FAILED RECIPIENTS" SCREEN

This screen appears when the transfer request is declined by the server. The user is then able to edit the request and send the edited request .

"NOT REGISTERED RECIPIENTS" SCREEN

This screen appears when the server recognizes that one or more of the recipients are not included in COPA' s database. The user is then able to create an 'External link' and\or 'External 2- way collaboration links' sending. By following this feature, the user is able to choose between 'direct end-to-end transfer' and 'upload to COPA' s server' options. "OUTGOING NOTIFICATIONS" SCREEN

This screen appears when the user selects the 'notifications icon .

'Outgoing request' will appear right after the user sends the request .

'Pending' status means that the user has sent a request and he is now waiting for the other user to accept the request.

'Process' status means that the transfer of the file is now in undergoing. In case that a number of files are being sent, the user has the option to view the details and the transfer progress of the different files.

'Complete' status means that the transfer request has been completed. If the transfer was an 'Advanced Security' type of transfer, the user may view and\or delete the file through the 'COPA Viewer' .

'Failed' status means that the transfer request has been stopped due to an error (e.g. connection loss) . The user may find out the reason for the failure by pressing the 'show error' button.

'Aborted' status means that the transfer request has been interrupted by one of the users.

INCOMING NOTIFICATIONS" SCREEN

This screen appears when the user selects the option to review the notifications.

The 'notifications' icon will increment the total new notifications number by one whenever there is a new 'transfer request' pending. The 'incoming' requests are displayed in this window tab. 'New' status means that the user has received a new request. The receiving user can then either 'confirm' or 'decline' the request. If the sending user choses to be identified by his 'security key' then when the receiving user chooses to accept the request, the receiving user will insert the sending user's 'security key' and only then 'confirm' the request.

In case of 'Advanced Security' requests, an 'Advanced Security files' label will be applied. When the transfer of the Advanced Security files is completed, the user has the option to open 'COPA-Viewer' list and view the advanced files. The user may watch his 'Advanced Security' files through the 'HOME screen' by pressing on the 'COPA Viewer' button. This screen will show 'Advanced Security files' entries and their expiration time.

When a time period defined for a given file reaches its expiration point, the file will be deleted from the local system and will no longer be accessible.

APPLICATION MAIN BLOCKS

The following section provides the application's main system blocks and the activities' flow before, during and after using the application .

REGISTRATION

In the registration step, the user provides certain personal information, followed by having the user verifying his account in response to an e-mail sent to him.

Once the user has verified his account, his information is retrieved by using a verification 'token' sent together with the verification email. If the 'token' has not expired, a new user entry is created in the database for storing the user's information. Preferably, the user's password is encrypted before it is saved in the database

LOGIN

The information provided by the user in the registration step, is forwarded to the COPA system's server. Then, when a login procedure begins, in order to authenticate the user, his e-mail address is used for retrieving his related information that was stored in the database during the registration step. The authenticating procedure continues by encrypting the password used by the user while login to the application, where the encryption of the password is the same encryption applied in the registration step. If the encrypted result matches the one already stored in the database, the user is authenticated. In addition, a 'socket. io- stream' event is created for the user, one that will be used to 'pipe stream' data from/ to the user when he transfers data via a tunnel to the intended recipient.

Optionally, a user details ' 'token' may be generated by the system which is then forwarded to the client (the user) , who can save it at a local storage of his, for further authentications.

As will be appreciated by those skilled in the art, the encryption of the password may be carried out by implementing any applicable method that is known in the art per se.

SECURITY KEY

All COPA users receive newly created session keys generated only by COPA' s server every time they access the application. The server combines features of NPM password-generator package with NPM package, together with Node.js Crypto library preventing the use of weak passwords if such are created manually by the user.

The security key combines two parts - an ID and a PASSWORD. The ID is designed to help the system to find users; entries in the database, whereas the password is used for authenticating the user. Each part is separately generated and is associated with a unique value. After the generation of these two variables, the two values of them are concatenated and sent to the user.

The COPA server encrypts the password part (similarly to the procedure carried out in registration step), creating a hash code, followed by deleting the passport part original value. The server concatenates the encrypted hash code and the ID, and then stores them in the database. This action ensures that the password's value is not being stored in the database and the only way to retrieve the value is by entering the same exact value once again.

Therefore, in order to retrieve one's information, the user would need to send that person's exact key values, which the COPA server would then convert into an ID and a password. The password value will be encrypted again by the server to get the hash code value, and then after concatenating the combination that comprises both the ID value and the hash code value, the server is able to retrieve the user's information and to match the key's values that were sent by the user. The security key is generated whether the user enables this feature or not.

ENCRYPTION FUNCTIONALITY

The use of encryption functionality (the Crypto Service) is for creating and managing each of the user's encryption keys. Encryption keys are created in order to encrypt all transferred data and chat messages.

The Crypto Service is used to generate several keys:

Streaming keys: both public and private keys that are used in a so-called classic sending method, whereby data is encrypted by the sender and decrypted by the recipient as soon as the recipient receives the data. New streaming keys are generated at the start of each session by using the ECDH (Elliptic Curve Diffie-Hellman) algorithm that creates key exchange objects. The key exchange object creates the public and private keys and retrieves the keys when needed. It also computes the secret key for encryption and decryption of the data being transferred. Advanced-encryption keys: public and private keys that are both used in carrying out an Advanced Security sending method, as well as for chat messages.

Advanced Security sending and chat messages are encrypted at the sender side and remain encrypted at the recipient's local system. The data is decrypted only when the recipient decides to open the file or the message, which can be done only through the application's display. Advanced Security message keys are generated in a different way from the streaming keys, as their generation relies on the use of a fixed private key generated and encrypted by COPA's server secret passwords associated with each respective user. When the user login to the system, the server decrypts the user' s private key with the server secret password and retrieves the public key as well, then it sends it to the user's application in order to encrypt and decrypt advanced files and chat messages.

SELF-ENCRYPTION

If a user has enabled this security feature, the 'Advanced Keys' that were generated and encrypted by COPA server secret password are being replaced with a newly generated keys that are encrypted by a password that is known only to the user. When the user enables this feature for the first time, he is requested to enter a password. This password is used in encrypting a generated private key. The encrypted private key is saved together with a public key at the system's database so even the system's server is unaware of the real private key. When this feature is enabled, in response to the COPA server's request that the user will enter his unique password each time the user is accessing the application, either to use chat option and/or the Advanced Security option. The user must activate his advanced keys by entering his unique password and then this password will be used to decrypt the private key, thereby allowing the system to create a new secret key for sending new messages and for sending advanced files and also to decrypt old messages and advanced files, received^

ENCRYPTION GROUP

According to an embodiment of the disclosure, the system provides an option for the user to generate an encryption. In other words, the user is able to generate several self-encryption keys which are stored at the system's database after their encryption by the user application.

This feature allows the user to set an encryption group and once this option is exercised by the user, the application decrypts only chat messages and Advanced Security files that are labeled under this encryption group.

CLIENT'S SERVER SERVICE FUNCTIONALITY

The COPA client service is configured to handle all the requests that are getting in and out of the user's application. This service creates the 'Client Server' . The 'Client Server' is an https server which is configured to generate a secured SSL connection with a self-signed certificate for each user, after the respective user has logged into the COPA system, in order to allow users to transfer data directly by applying 'Ports Connection' option or by a 'local sending' transfer option, to each other without having a third-party server intervention there-between. SSL Certificates are small data files that digitally bind a cryptographic key to an organization's details. When installed on a web server such as the main COPA server (e.g. a signed certificate from a certification authority such as for example goDaddy) or on the clients' servers (self-signed certification), it activates the padlock and the https protocol and allows secure connections from the web server to a browser or in from a COPA Client to the COPA Main Server and between COPA clients' servers themselves .

The COPA Client server receives https requests or socket io stream transfer events from various users and generates (and holds) an array of JSON Web Tokens (JWTs) . Then after a 2-Handshake- Validation procedure has been successfully completed with the two users, the client server is configured to forward the tokens to the user who requires access to the client server on each request. Preferably, these tokens should have an expiration time.

Next, after the 2-Handshake-Validation procedure has been successfully completed, if the transfer is carried out via 'Ports Connection' method or by 'Local Sending' transfer, then the client server would start listening to a specified port. This action would prevent the client's server from allowing requests at all times, which would subsequently raise the probability of receiving malicious requests. With this precaution, the client's server will only be available for those requests and responses that are transmitted within the right time period. When the client server receives a request, it would validate the request by matching token signatures. If the token is an unknown token or is tampered or has expired, the server will abort the request. Otherwise, the client server would address the request using the appropriate transfer method .

"2-HANDSHAKE-VALIDATION" PROCEDURE - TRANSFER REQUEST

In order for user A (a sender) to be able to transfer data to a different user (User B, the recipient), the sender must know user B's email, username or 'security key', depending on which identification type user B selected. User A can retrieve this information by using the COPA application's chat feature or by using any other means of communication. After retrieving user B's identification value (email, username or 'Security Key'), user A selects files from his local system and together with user B' s 'security key' if user B's identification is done by security key or a given username, or email, the application will start packing an 'approval object' that will contain value information regarding the transfer request, such as email or username or the key and the session's password (retrieved from the 'security key') of user B in case that user B's 'security key' identification was set, as well as information that relates to the files (filename and size) and/or any other attributes that would assist at a later state in determining which transfer method is required for carrying out this request.

After packing the 'approval object', it will be sent by the application to the COPA server. The server validates the parameters of the request - in order to ensure that they are the exact required parameters .

If the expected parameters are indeed received, information that will be forwarded to user B, is retrieved from the system's database according to the identification parameter, if that user' s identification is set to the identification parameter that user A had entered, then if a match is found between the two, the validation is considered successful, otherwise - the validation is considered failed. In case user B's identification is the user B's 'security key', then user B's security password is validated if it matches the approval's password parameter.

This validation is carried out by implementing the same password validation process as mentioned above. If the validation process succeeds an 'approval object' that is composed of user A' s socket ID and user B's socket ID is generated and stored in the system's database. After storing the 'approval object' at the system database, an e-mail notification may be sent to user B's email address. In addition, the original approval object is sent to user B and a new request composed of the 'approval object' is generated for both users .

"2-HANDSHAKE-VALIDATION" PROCEDURE - TRANSFER CONFIRMATION

In order for user B to receive data sent by user A, he should be aware of the sender's (user A) 'security key' if user A' s identification is indeed by his security Key.

User B may retrieve this information by using the COPA application's chat feature or by using any other means of communication. After retrieving user A' s 'security key' and provided that user A' s identification is his security key, user B may accept the request by simply entering user A' s 'security key' . If user A' s identification parameter is his email or his username, then user B may immediately confirm the request. The application then retrieves user B's encryption public key (streaming or advanced, depending on the method applied for the sending process), IP address, port identification, and confirms whether user's B port is active (when either 'Ports Connection' or 'Local Sending' methods is applied) . Then, the 'Client Server Service' indicates to the user's 'Client Server' to start listening on the port identified if open, and if not, on a randomly selected port) when local sending process is implemented. Thereafter, creates a request token is generated in a way mentioned hereinabove.

The application packs all the required approval information and sends it to COPA's server. The COPA server validates the approval parameters. If user A is identified by his 'security key' the validation is carried out as described above. If not, the validation is carried out by retrieving information from the 'approval object', and if the server receives the correct parameters, then the validation procedure is successfully completed. If the validation procedure has been successfully completed, by retrieving information on user A from the database, user A is identified. In the case where user A' s identification is by his 'security key', then the system (COPA) server validates the 'security key' as mentioned above. If the relevant validation is completed successfully, the server updates the database that the approval process (the 2-handshake- validation) has been successfully completed, and the system's server sends the original approval back to user A and to user B, where the request objects and status are updated, and thereafter the transfer process will begin .

PORTS' CONNECTION TRANSFER PROCESS - TRANSMITTING END

Following the successful completion of the 2-handshake- process, the sender (user A) prepares a request object by following the steps :

(1) computing an encryption secret key by the recipient's (User B) encryption public key, together with user A' s encryption private key;

(ii) if user B' s port is active (i.e. the port is open) as retrieved from the approval's object, retrieving the information needed for the transfer, such information may comprise request JWT, user B' s port and IP address, files information (name, size), etc . ;

(iii) generating a counter for the request transfer that may be applied by user B to become aware which file is about to be transferred prior to starting the data streaming data;

(iv) creating an HTTPS POST request addressed to user B' s 'Client Server' and a readable stream of data;

(v) creating a cipher object with the computed secret key for this request;

(vi) channeling the readable request stream of data to the cipher stream and the cipher stream to the request stream, and once this step is completed, the transfer begins; and (vii) if user B' s port is not active (open), checking whether user A' s port is open. If user A' s port is open, then user A starts listening on his port and generates a new token (JWT) , followed by passing the requested update details (IP, port, etc.) to the system server where the system server validates the parameters, retrieves the required approval from the database and sends the information back to the recipient.

DIRECT TRANSFER PROCESS - RECEIVING END

The recipient (user B) will either get user A' s request and respond to it as mentioned hereinabove or will receive a signal indicating that he should initiate the transfer (in case user B' s port is closed but user A' s port is open) . In the latter case, user B will start the same process as described-above, but this time with an HTTPS Get request, writable stream and a decipher object .

When user B receives a file, a corresponding temporary file is created, and when the file transfer is completed, the temporary file name is changed into the file original name. If the transfer process is unexpectedly stopped before its completion, the transfer process may be resumed by requesting to begin a new 2- handshake-validation procedure, during which the request's parameters will be updated by searching on user B' s side (receiver) for the temporary file. If a temporary file is detected, its size is retrieved, or if the original file name exists that means that the transfer has been completed and thereafter the transfer counter would be increased by the value of "1". If the temporary file or the original file name are not found, the transfer of the file would not continue, and the system will start from the beginning of this file. After the retrieval is resumed, the file information and the 2-handshake-validation procedure is completed, the system will proceed with the transfer process as above, with the exception that this time the updated parameters will be used. Thus, if the temporary file is found, the system will start sending the file from the temporary file size minus the stream chunk size, in order not to lose data. However, if the original file name is found, the system will move to the next file if such file is available, and if neither the temporary file nor the original file name are not found, the system would start sending the file from its beginning.

TRANSFER PROCESS - SENDING WITHIN A LOCAL NETWOK

When the 2-handshake-validation procedure is implemented, the recipient (user B) requires to check if his port is open.

As mentioned above, user B creates and forwards a JWT, his port identification (if available, if not then the application selects a random port), local IP network identification and his IP address. When the sender (user A) gets the approval information, he preferably checks if both users are part of the same network, by sending an HTTPS request to user B local address. If user B successfully receives a matching JWT, he will respond back to user A, and thereafter user A will start the transfer process, by which in this case he will send the file through user B' s local address. If there is no response, then a regular direct sending or tunnel sending would apply.

TUNNEL TRANSFER PROCESS - TRANSMITTING END

Once the 2-handshake-validation procedure has been completed, the sender (user A) prepares a request object in accordance with following steps:

(i) computing an encryption secret key by the recipient's (user B) by encrypting a public key together with user A' s private key . (ii) retrieving user A' s socket ID as well as all the information required for the file transfer, such as a request JWT, user B' s socket ID, files information (name, size), etc.

(ill) generating a counter for the request transfer to allow user B to be provided with information that relates to the file is about to be received by him, prior to the beginning of the data streaming .

(iv) creating a stream object by a module for bidirectional binary data transfer with stream API. In addition, a readable stream is created.

(v) creating a cipher object by using the computed secret key associated with this request.

TUNNEL TRANSFER PROCESS - RECEIVING END

After creating a tunnel via the server, an object will convey an event to the recipient (user B) and user B will receive the tunneled stream object with the additional transfer information. User B then authenticates the sending with JWT parameter retrieved from the information object. If there is a match and the JWT was not tampered, user B will start processing the transfer request by creating a writable stream, decipher the object using among others the computed secret key from the additional information object.

Then the tunneled stream is conveyed to the deciphering stream and the deciphering stream to the writable stream, which marks the beginning of the data transfer.

User B manages the file conveyance process in a way similar to that described-above for user B under the section "ports connection transmitting end".

ADVANCED SECURITY TRANSFER PROCESS - TUNNEL TRANSMITTING END

After creating the tunnel by the system server, socket. io- stream object sends an event notification to the intended recipient (user B) who will receive the tunneled stream object with additional transfer information. User B will then authenticate the sending by JWT parameter retrieved from the information object received .

If the authentication is successful (i.e. a match is found for the JWT parameter retrieved from the information object received and the JWT was not tampered) , user B starts processing the transfer request by creating a writable stream.

Unlike the case of regular streaming, the 'advanced security' transfer takes the tunneled stream and has it conveyed immediately to the writable stream without decipher the data, which marks the beginning of the data transfer. Skipping the deciphering part allows keeping the file encrypted on user B' s local system (receiver) , therefore the file may be viewed only while using the COPA application.

User B manages the file conveyance process in a way similar to that described-above for user B under the section "direct transmitting end".

ADVANCED SECURITY SERVICE

This service manages all the advanced files. Advanced files are files which enable a "self-destructive" process. These files remain encrypted on the recipient's local system and are not decrypted unless the user chooses to open them at the application screen. The advanced security service is configured to receive files by using advanced security sending (transmission) after the transfer process has ended, and to create a suitable advanced security file object. This advanced security object provides the path to the file, the time left for the file before will be deleted as well as the sender's public key. The advanced security object is the entity responsible to delete the file when the pre-set time period has expired. Advanced security object is also responsible for updating the "advanced security time" parameter which indicates the time left for the file to stay "alive" (before being deleted) , which is calculated by taking the value of mirageTimeDiff as mentioned herein and adding it to the current time value (mirageTime) .

Next, the "self-destruct function" is created by applying the received advanced security file information and scheduling an erase function, e.g. which can be scheduled for deletion say on a specific date. The value of the mirageTime is combined by the delete file function with the file path information, thereby creating a self-destruct function for the advanced security object .

Once the advanced security object has been created, the user is able to watch a file characterized as an advanced security file only on the application screen (i.e. when using the application) . In order for user B to be able to watch advanced security files, he would have to activate his 'self-encryption keys' in the case that the 'self-encryption' feature is enabled, otherwise the activation occurs in the background (with the default generated keys by the server) . After the activation, user B can watch the files by using the COPA application.

If the 'self-encryption' feature is enabled, user B activates his self-encryption keys by entering his own self-encryption password. With this password, the system is able to decrypt user B' s self-encryption private key by creating a deciphering object wherein user B' s password is taken into account (the secret key for the private decryption key) . Then user B's original self encryption keys become retrievable. Upon retrieving the original self-encryption keys, it becomes possible to decrypt advanced security files so when user B selects to open such a advanced security file, user B original self-encryption private key is taken together with user A' s public key that has been retrieved from the advanced security file object, for creating a deciphering object. Next, a readable stream is created with the proper encoding type according to the file type as derived from the advanced security file object and is linked with the encrypted advanced security file. Thereafter, it is possible to pipe the readable stream to the decipher object and the result is forwarded directly to the application's advanced security display without saving it at the user B' s local system.

This approach is adapted to prevent user B from forwarding the advanced security file out of his folder and have it displayed/printed while using a different platform. Because the file is encrypted, user B cannot have the file opened outside of the application.

PRINT SCREEN FUNCTIONALITY

According to an embodiment of the present disclosure, certain precautions are taken to ensure the requested results when using the advanced security file option. One such precaution is to detect and act on the use of a "Print Screen" shortcut.

According to this embodiment, the system is configured to detect when the user presses the global keyboard shortcut, being a system-wide hotkey designated for "Print Screen". When the user hits this key (Print Screen) , an event is generated that is detected by the system. By detecting the generated event, the system according to this embodiment overrides the global shortcut functionality, thereby preventing the user from printing the content of the advanced security file by pressing the Print Screen key .

EXTERNAL LINK TRANSFER REQUEST - PROCEDURE

When user A (a sender) inserts one or more email addresses that are not included in the system's database, the server would recognize that and would return a message to user A, requesting to know whether user A would like to create an external link for communicating via the COPA system to a non-COPA user. If user A responds in the affirmative, the application requests user A to enter a unique password, which will have to be provided later on by user B (the non-COPA user) in order to proceed with the process. After entering the password by user A, if the user wishes to carry out a peer-to-peer file transfer, the application creates a new JTW and adds it to the JWT whitelist. Then the application would gather necessary details for carrying out the transfer such as: JWT, streaming public key, user B' s email, file's name and size, etc. When the application has gathered the requested information, it sends the request to the system server. The server creates an 'approval object' by using user A' s ID and user B' s email address, and optionally by using the necessary information for the transfer. Furthermore, the server creates a 'Downloader Access Token' object. Before generating an Elliptic-curve Diffie-Hellman (ECDH/ key, the private key is encrypted and passed to the 'Downloader Access Token' object. The access token object holds the encrypted private key and the generated token with an expiration date that will be passed along an external link for the validation of user B later on. The server then establishes an external link with the token attached to it and sends an email to user B specifying the established external link.

EXTERNAL LINK TRANSFER CONFIRMATION - PROCEDURE

When user B (the non-COPA recipient) accesses the external link established by the system's server he would being redirect to COPA website server. The website server extracts and validates all the required parameters from the link and then renders a transfer page. Based on the transfer page, a socket connection with the system server is established. User B is requested to enter the authentication password generated by user A (the sender) . Then the website server would gather required information such as transfer token, user B' s socket ID, and will send a request API to the system server. The request token is then extracted from the header in order to validate that the 'Downloader Access Token' for this request is available and that the parameters required for the transfer indeed exist in the system database. Next, the system server matches the password which user B has entered with the password which user A has entered. If the password that user B has entered matches that which user A had entered, the system server registers user B's socket ID as the one via which the transfer tunnel will be created by the system's server. The server then extracts the various files' details such as name, size, and returns them to the transfer website page. User B may then press on each file download link, thereby starting the transfer request. When user B selects a file download link, the website server gathers the required parameters such as request token, 'Approval Object' ID, files information together with a socket . io-stream object and a callback function. The website server fires an event to the system server with the required parameters, and the system server again validates the token. If this validation is successful, the system fires an event to user A, and the application installed at user A' s client server retrieves the JWT from the JWT whitelist and will try matching it with the one extracted from the request parameters. If that matching is successful, user A's application computes a secret key particularly for this request, retrieves the right request, creates a readable stream pointed to the file path on A's local system, and creates both a socket . io-stream object and a cipher object. User A then returns with the callback function parameter and with parameters required for creating the tunnel such as the socket stream object. Only then user A stats piping the readable stream to the cipher stream and from the cipher stream to the socket stream. By activating the callback function parameter, the server is able to create the tunnel stream for both user A and B's streams. When tunnel stream is established, user B begins receiving chunks of file's data and creates a blob for the user to be able to download the file through the browser. When the transfer is completed, the system server deletes the 'Downloader Access Token' and this link is no more available for a further use .

EXTERNAL 2-WAY COLLABORATION LINKS - PROCEDURE

When a COPA user (user A) adds a non-COPA user (user B) to his contact list, The COPA application checks if user B' s email has not already been registered in the system database as a non- COPA user. If user B's email does not appear in the system database, then the server would create a new non-COPA user. To do that, the server generates a new password (similarly in the way described above), and a JWT token for link's validation. The server then sends an email to user B indicating that user A has created a 2-way collaboration link for user B to send files back to user A together with his login credentials. Then user B can activate the link and in response he will be redirect to the Sender-Login page on COPA's website. The login procedure is similar to the login procedure mentioned above but this time the encrypted hashed password will be matched with the hashed password within the non peer's receivers array object, retrieved from the database by the link's token load.

After validating user B's credentials by the server, it sends back an access token for gaining user B access to the relevant functions of the server. This token has an expiration time and can be regenerated only by a refresh token received at the server together with the old token. If the token expires and there is no valid refresh token, user B will be logged out and be redirected to the Sender-Login Page. After user B is logged in he will be transferred to the Sender-Dashboard page where he can create a request that will be sent to user A. When Sender-Dashboard page is uploaded, the token is validated, using the application web-sender policy, and once validated, a new socket. io connection is generated for user B to COPA's server and an event listener for the new socket is generated at the COPA's server for detecting when does user B start streaming data. The server then returns with information identifying whether user A has created an external 2- way collaboration by implementing a peer-to-peer method or by uploading to the server method. If the selected method is "upload- to-server", then once user B's selects files to be transferred, the COPA application encrypts and uploads the files into a request on COPA's server, the same way as mentioned above, using the ECDH key exchange algorithm. After uploading all the files that should be transferred, user A receives a new request from user B that comprises all the request information, such as files information and sender information.

At this stage, user A may determine whether to accept the request or to decline it. If user A accepts the request, then the download procedure continues the same way as was mentioned above.

If the external 2-way collaboration link created by user A is for implementing the peer-to-peer transfer method then when user B selects files the COPA system generates a request object with the files information such as the files' names and sizes, user B's socket id and user B' s access token, which is then sent back to the COPA server. The COPA server first validates the token by detecting if the token has been tampered, in which case the request will be blocked. Then the server gets the token loads and retrieves user B's object (of the non-COPA user) and user A' s object (the COPA user) from the database, followed by creating an approval object as mentioned above. The server then sends the request approval to user A and the request confirmation is sent with an addition that indicates that user B is indeed an external 2-way collaboration user within user A' s contact list. If user B' s request is declined, then the files are being stashed and a proper message will be provided. If user A accepts the request, then the files to be transferred are encrypted similarly to the above description using the ECDH key exchange and a socket . io-stream object is created. All the required parameters are conveyed with the socket stream event and are watched by the registered event listener as was mentioned above. The COPA server then validates again that user B has a valid access and if in the affirmative, is the server retrieves user A' s socket ID and creates a streaming tunnel that extends between user A and user B. Once the COPA server creates the streaming tunnel, the remaining of the transfer procedure is carried out the same way as was mentioned above.

ENCRYPTED LOCAL FOLDER - PROCEDURE

COPA application creates a default folder when first installed with this feature. User A may change the folder's location at any time he wishes to do so. COPA application creates random folder encryption keys by default for each user. These encryption keys allow COPA application to encrypt and decrypt files located with the 'Encrypted Local Folder' . COPA application watches this folder whenever the application is active and immediately encrypts any file that has been inserted into this folder since the last time that the application was active. User A will be able to decrypt a specific file or all the files from the 'Profile Settings' . By pressing 'Disable encryption folder' button, COPA application retrieves the encryption keys and decrypts the folder similar to the way that was described above. Similarly, mutatis mutandis, user A may enable the encryption and the files will return to their encrypted form. Preferably, the files' folder is provided with a list of contacts that are permitted to view the list of files. User B (who is recognized by the system as a user whose identification is included in user A' s contacts' list) to whom such a permission was granted, is able to see user A' s list of files located at the encrypted local folder. When user B activates his application, the system's server checks if user B has any encrypted folder permissions, if so, an array of granted users will be sent to his COPA application. When user B enters thereafter user A' s encrypted list at his own COPA application, the system server would first validate that user B is provided with user A' s permission to view the list of files. If in the affirmative, the server sends a request to user A and retrieves information associated with the list of files comprised in the encrypted folder, so that it can be forwarded to user B. In addition, user A creates a JWT token and adds it to his JWT whitelist, and then will send the JWT together with the files information and user A' s public key back to user B. After selecting by user B a file name from user A' s list, a 'Tunnel Transfer' is initiated, similarly to the way described above. Furthermore, user A may grant a permission to user B so that user B will be notified every time there is a new file added to the 'Encrypted Local Folder' of user A. If a new file is added, the COPA application preferably retrieves all users that appear in user A' s contact list who were granted permission as described above, and sends a notification to these users, indicating the addition of the new file.

AUTO SEND MODE - PROCEDURE

According to an embodiment of the invention, there is provided an automatic send mode that can be applied by the COPA users. In this example, user A may determine whom out of the contacts included in his/her contact list will be associated with the feature of auto send mode.

Let us assume that user B has been identified by user A as a contact who should be associated with auto send mode. Once this identification has been received by COPA server, it will create a field in its database for user B within user A' s contact list that corresponds to the auto send field, and will set it to "true"s.

In the process described-above under the 'Encrypted Local File' section, upon detecting by the COPA application that a new file was added to user A's Encrypted Local Folder, the COPA application retrieves user A's contact list and will check for any user included in that list that is designated as being associated with the auto send feature. Once the COPA application identifies such a user (or users) e.g. user B, it creates a new request and sends that request to the COPA server which in turn transfers the request to user B in a way described above.

AUTO RECEIVE MODE - PROCEDURE

According to another embodiment of the invention, there is provided an automatic receipt mode that can be applied by the COPA users. In this example, user A may determine whom out of the contacts included in his/her contact list will be associated with the feature of auto receive mode.

Let us assume now that user B has been identified by user A as a contact from whom user A wishes to automatically receive files, i.e. a user who should be associated with auto receive mode. Once this identification has been received by COPA server, it will create a field in its database for user B within user A' s contact list that corresponds to the auto receive field, and will set it to "true" .

In a process of conveying the files' transfer request from user B to user A, the COPA server checks if user A has designated user B as an entity from which he wishes to automatically receive such files, and according to the COPA server's findings, it will add a Boolean variable to the transfer request.

When the terminal of user A receives that modified transfer request, it will check the added variable. If this variable is set to the value "true", the system would skip the step of accepting (by user A) the transfer request, and will automatically confirm the transfer request.

Once the auto confirmation has been made, the rest of the process remains the same as in every other transfer procedure described-above .

EXAMPLE

Following is an example of a method for carrying out an embodiment construed in accordance with the present disclosure, in which the transfer request used comprises 'security key', and the 'self-encryption' functionality is enabled.

In step 100, both user A and user B login to the COPA application and receive a newly generated security key.

Next, (step 105), user A initiates a 'send request' by uploading data, then inserting user B' s security key or by adding a user that appears in a pre-defined contact list of confirmed users, followed by and pressing the key defined as the application transfer button.

The system server checks the security key of user B (step 110) . If the server is able to retrieve the required information associated with user B, it creates a new approval object (step 115) . Furthermore, the server will add the IDs of user A and user B to the IDs database, to the "from" and "to" parameters of the approval object, respectively.

The server then sends a request attached to the approval object to user B and await his response (step 120) . User B inserts user A' s security key or if user A already exists in his pre defined contact list then immediately press the confirm button (step 125) .

The COPA server then checks the token of the approval object (step 130) . If the server is able to retrieve user A' s information successfully, it will add to the approval object - without saving it at database - information that relates to user B, such as his IP address, port identification, socket ID, etc. and will change the value of "confirm" parameter to true.

Only then, the server will send both users the approval object (step 135) .

Next, when user B realizes that the value of the approval object is true, he will insert user A' s approval token into the JWT whitelist and will start listening for incoming requests (step 140) .

User A who also receives the approval object, will check whether the confirm value is "true" . If in the affirmative, he will retrieve user B' s IP address and port identification or user B' s socket ID (step 145) .

Once both users have acquired all the details that are required to carry out the transfer process, the send process will begin (step 150) .

After the transfer process has been completed, the approval object is discarded, the approval token of user A is deleted from user B' s client server requests, JWT whitelist and either user B' s client Server or user A' s client server will cease listening to the designated port, which will then be closed (step 155) .

Fig. 2 is a block diagram of an example of components of the system for carrying the method exemplified in FIG. 1. In one embodiment, the system may include a bus 200 (or other communication mechanism) that interconnects subsystems and components for transferring information within system 100. For example, bus 200 may interconnect a processing device 202, a memory interface 204, a network interface 206, and a peripherals interface 208 connected to I/O system 210. Processing device 202, shown in Fig. 2, may include at least one processor configured to execute computer programs, applications, methods, processes, or other software to perform embodiments described in the present disclosure. Such a processing device may be for example, 4 Intel (R) Xeon (R) CPU E3-1225 V2 @ 3.20GHz, 64-bit capable and having 32GB RAM.

The term "processing device" refers to any physical device having an electric circuit that performs a logic operation. For example, the processing device may include one or more integrated circuits, microchips, microcontrollers, microprocessors, all or part of a central processing unit (CPU) , graphics processing unit (GPU), digital signal processor (DSP), field programmable gate array (FPGA) , or other circuits suitable for executing instructions or performing logic operations. The processing device may include at least one processor configured to perform functions of the disclosed methods such as a microprocessor manufactured by Intel™ or by AMD™. The processing device may include a single core or multiple core processors executing parallel processes simultaneously. In one example, the processing device may be a single core processor configured with virtual processing technologies. In another example, the processing device may include a multiple-core processor arrangement (e.g., dual, quad core, etc.) configured to provide parallel processing functionalities to allow a device associated with the processing device to execute multiple processes simultaneously. It is appreciated that other types of processor arrangements could be implemented to provide the capabilities disclosed herein.

In some embodiments, processing device 202 may use memory interface 204 to access data and a software product stored on a memory device or a non-transitory computer-readable medium. For example, system 100 may use memory interface 204 to access memory device 212. Memory device 212 may include high-speed random access memory and/or non-volatile memory such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR) . Memory device 212 may store an operating system, such as LINUX, iOS, UNIX, OS X, WINDOWS, or an embedded operating system such as VXWorkS . The operating system can include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, the operating system can be Ubuntu 14.04.5 LTS.

As used herein, a non-transitory computer-readable storage medium refers to any type of physical memory on which information or data readable by at least one processor can be stored. Examples include random access memory (RAM) , read-only memory (ROM) , volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, a cache, a register, any other memory chip or cartridge, and networked versions of the same. The terms "memory" and "computer-readable storage medium" may refer to multiple structures, such as a plurality of memories or computer-readable storage mediums located within system 100, or at a remote location. Additionally, one or more computer-readable storage mediums can be utilized in implementing a computer-implemented method. The term "computer- readable storage medium" should be understood to include tangible items and exclude carrier waves and transient signals.

In some embodiment, the system may include network interface 206 coupled to bus 200 that is configured to provide a two-way data communication to a communications network. In one embodiment, network interface 206 may include an asymmetric digital subscriber line (ADSL) card, cable modem, or a satellite modem. As another example, network interface 206 may include a local area network (LAN) card to provide a data communication connection to a compatible LAN. In another embodiment, network interface 206 may include an Ethernet port connected to radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of network interface 206 depends on the communications network (s) over which the system is intended to operate. For example, in some embodiments, capturing device 105 may include network interface 206 designed to operate over a GSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth® network. In any such implementation, network interface 206 may be configured to send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information .

The COPA system may also include peripherals interface 208 coupled to bus 200. Peripherals interface 208 may be connected to devices and subsystems to facilitate multiple functionalities, such as for example printing the outcome obtained by executing the algorithm disclosed herein for a given individual. In one embodiment, peripherals interface 208 may be connected to I/O system 210 configured to receive signals or input from devices and providing signals or output to one or more devices that allow data to be received and/or transmitted by system 100 (e.g. retrieving data to be used while executing the algorithm disclosed herein) . In one example, I/O system 210 may include a touch screen controller, an audio controller, and/or other input controller ( s ) . The touch screen controller may be coupled to a touch screen and can, for example, detect contact, movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive and infrared technologies as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch screen. In addition, I/O system 210 may include a display screen (e.g., CRT or LCD) in place of the touch screen. The audio controller may be coupled to a microphone and a speaker to facilitate voice- enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

WHAT IS CLAIMED:

1. A method for enabling transfer of peer-to-peer secured data from a first user to a second user along a communication path established by a server which is configured to communicate with each of said two users by using their respective IP addresses and/or socket IDs, and wherein said method is characterized in that said server is further configured to generate tunnels for streaming data directly between said users, and wherein said server is not exposed to data being transferred between said two users.

2. The method of claim 1, comprising the steps of:

(ii) initiating by the first user a request for establishing a transfer session by uploading data that comprises a security key associated with the second user or comprises an identification of the second user, provided the identification of the second user together with other parameters associated with the first user are included in a pre-defined list of authorized users;

(iii) checking by the server the security key associated with the second user, and wherein if the server is capable of retrieving required information associated with the second user, the server is configured to create a token of a new approval object, and adding IDs of the first user and the second user to a database adapted to store data associated with users of the application;

(vi) checking by the server the token of the approval object, wherein in case the server is capable of successfully retrieving required information associated with the first user, the server will update the approval object by adding that information thereto, without storing information that relates to the second user, and will change a value associated with a first parameter to a pre defined value;

(vii) sending by the server to both users the updated approval object token;

3. The method to claim 2, wherein step (ii) further comprising confirming email addresses and/or usernames associated with the second user.

4. The method of claim 2, further comprising a step of:

(xi) upon completing said data transfer process, discarding the approval object, deleting the approval token of the first user from a list of requests to be displayed at the second user's client server .

5. The method of claim 1, wherein said first user is configured to control data that had already been transferred to the second user while carrying out said data transfer process.

6. The method of claim 5, wherein said control comprises associating data transferred with a pre-determined deletion time, at which time the transferred data shall be removed from the second user system, without leaving any copy thereof that can be accessed from the second user system.

7. The method of claim 5, wherein said control comprises providing said first user with an option to cancel the transfer of data, after the path generated for said data transfer has already been established.

8. The method of claim 2, wherein said method further comprising a step of checking by said server whether the first user and the second user are located within a single local network, and if in the affirmative, carrying out said data transfer process within said single local network.

9. The method of claim 1, wherein the data to be transferred in the data transfer process, is encrypted by the first user without providing said server with any means to decrypt the encrypted data.

10. The method of claim 1, further comprising a step whereby the second user generates at his own local system a token, which is transferred to the first user, and upon its receipt by the first user, said second user verifies that the token is a legitimate token to be used in the system, and transferring said data stream after such a verification is obtained.

11. The method of claim 1, wherein said first user whose identification is stored in a database comprised in said server, initiates the establishment of the communication path for the transfer of peer-to-peer secured data to a second user whose identification is not currently stored in a database comprised in said server.

12. The method of claim 1, wherein said first user whose identification is stored in a database comprised in said server, initiates the establishment of the communication path for the exchange of peer-to-peer secured data with a second user whose identification is not currently stored in a database comprised in said server.

13. The method of claim 2, further comprising a step of generating random encryption keys associated with said first user, for use in encrypting and decrypting files located at a pre-defined folder of the first user device and wherein upon adding a new file to said pre-defined folder, automatically encrypting the newly added file.

14. The method of claim 1, wherein the transfer of peer-to-peer secured data from/to the first user to/from the second user is carried out automatically in response to adding a new file to a pre-defined folder located at the respective user device.

15. A non-transitory computer readable medium storing a computer program for performing a set of instructions to be executed by one or more computer processors, the computer program is adapted to perform a method for enabling transfer of peer-to-peer secured data from a first user to a second user, according to claim 1.

16. A set comprising at least one non-transitory computer readable medium storing a computer program for performing a set of instructions to be executed by a plurality of computer processors, the computer program is adapted to perform a method for enabling transfer of peer-to-peer secured data from a first user to a second user, which comprises the steps of:

(ii) initiating by the first user a request for establishing a transfer session by uploading data that comprises a security key associated with the second user or comprises an identification of the second user, provided that the identification of the second user together with other parameters associated with the first user are included in a pre-defined list of authorized users;

(iii) checking by a server the security key associated with the second user, and wherein if the server is capable of retrieving required information associated with that second user, the server generates a token of a new approval object, and adds IDs of the first user and the second user to a database adapted to store data associated with users of the computer program (i.e. the application) ;

(v) sending by the first user user to the second user a security key, or an identification of the first user, provided the identification of the first user together with other parameters associated with the second user, are included in a pre-defined list of authorized users;

(vi) checking by the server the token of the approval object, wherein in case the server is capable of successfully retrieving required information associated with the first user, the server will update the approval object by add that information thereto, without storing information that relates to the second user, and will change a value associated with a first parameter to a pre defined value;

(vii) sending by the server to both users the updated approval object token;

(ix) upon determining by the first user that the value of the first parameter is that pre-defined value, retrieving by the first user information that relates to the second user (e.g. his IP address and port identification or his socket ID) ; and

17. The computer program of claim 16, wherein step (ii) further comprising confirming email addresses and/or usernames associated with said second user.

18. The computer program of claim 16, wherein the method further comprises a step of:

(xi) upon completing the data transfer process, discarding the approval object, deleting the approval token of the first user from a list of requests to be displayed at the second user terminal

19. The computer program of claim 16, further configured to enable the first user to control data that had already been transferred to the second user while implementing the data transfer process.

20. The computer program of claim 16, wherein the method further comprises a step of checking by the server whether the first user and the second user are located within a single local network, and if in the affirmative, carrying out the data transfer process within that single local network.

21. The computer program of claim 16, wherein the data to be transferred in the data transfer process, is encrypted by the first user without providing the server with any means to decrypt the encrypted data.

22. The computer program of claim 16, wherein the method further comprises a step whereby the second user generates at his own local system a token, which is transferred to the first user, and upon its receipt by the first user, verifying that the token is a legitimate token to be used in the system, and transferring the data stream after obtaining said verification.