Hallo All!
I'm a developer responsible for the Avast Remote Assistance (ARA) component, then I'll try to reply some of your questions about the ARA security.
The security of the ARA component has been one of the major requirements during the component development process.
We are using strong cryptography methods (SSL to establish a session and verify the ARA server identity and AES 256 to protect the Remote desktop data transfers) to keep users secure.
At first, when the request for the ARA session is created, the Avast! workstation initiate the SSL connection to the ARA server and verify the server certificate, if it belongs to the ARA subsystem. It protect users against fake servers, which can be used by attacker to hijack the ARA session (Man in the Middle).
Server generates the ARA ticket, which is delivered by the SSL connection to the user (Assistance Requester).The SSL connection keeps alive during this time.
Now, the ticket is delivered to the Assistance Requester and ARA server is waiting for second connection from Assistance Provider.
The Assistance Requester have to deliver the Assistance ticket to other side (Assistance Provider) to allow second user to connect to his computer and establish full remote assistance session.
Here is on user responsibility to deliver the ticket securely to other side. Avast! cannot take any responsibility if the ticket will be stolen during the transfer. We recommend to use cellular phone, or encrypted e-mail (PGP for example) or SKYPE message or call (Skype is using strong encryption to protect session communication) to do this. Use ICQ or normal e-mail message for example is not recommended, because any e-mail can be sniffed by attacker on any part of the e-mail path.
The ARA component is as secure as secure is the Assistance ticket! Choose the communication channel which you really TRUST!
When the ticket is delivered to the Assistance Provider, then he uses the ticket to establish the full ARA session. Mechanism is same -> use SSL connection to verify the ARA server and protect the communication, then send the ticket by this secure connection to the ARA server
When ticket is verified and both SSL connections from both user are paired on the server, then both sides goes to establish new data connections which carry the Remote desktop data. These data are shifted from one connection to other by the ARA server, but in encrypted (AES 256)form. The encryption keys are randomly generated and delivered to both sides of connection by established SSL connections, and then is granted that those keys cannot be stolen by a third party.
Due this, the Remote desktop data can be only decrypted by Assistance Requestor / Provider workstations and by ARA server proxy, but no one else.
I have to notice that encryption keys are visible for ARA server, because it works as proxy between both sides of the ARA session. Avast! will never decrypt any kind of communication belongs to any ARA session!
As somebody mentioned here, if you do not trust to AVAST!, do not use this piece of software.
If a data connection will be "stolen" or redirected by an atacker, then is not possible to use this connection for access to the Requester workstation, because the connection will deliver only binary noise to attacker -> the encryption keys are never transmitted in unencrypted form.
Additionally, the Remote Desktop server on the Assistance Requester side is started only when the Provider will initiate the session, and it listen only on localhost interface and on random port , then is not possible to connect on this server from outside.
All ARA connections are initiated from AVAST! workstations, then security of those connections is same as for example your web browser SSL secured connections or SSH sessions to your servers...
ARA doesn't use any server listening on Avast! workstations. It is provided on ARA servers, which are hardened and monitored by AVAST! IT profesionals.
I believe that this post help to understand the ARA principles of work and explain how the ARA security is implemented.
Of course, if you have any additional questions, let us to know, ad we will try to answer it ASAP.
Zdenek
