5 Replies Latest reply on Jul 16, 2014 12:21 PM by cryptor81

    EEFF to FRP Issue with sending encrypted files via email

    cryptor81

      Hi everyone,

       

      We have recently upgraded our EEFF 4.x software to the new version of File and Removable Media Protection 4.3.0.224.  After the upgrade we noticed very unusual behavior in FRP when dealing with the emailing of encrypted files.  In EEFF we were able to take a file that was encrypted on a computer's local hard drive with a specific encryption key, drag it into an email or use the attach a file feature in Outlook, and send the encrypted file in its encrypted state.  In the new version of FRP, this behavior has now changed and as soon as someone attaches an encrypted file into an email, regardless if it is via Outlook, GMAIL, Yahoo, or some other email application, the file loses its encryption and is sent out in a decrypted status! I have setup a policy for "Encryption Options" and have added processes like Outlook.exe and iexplore.exe in the blocked processes section.  Now if I try to send out a file that is already encrypted by either attaching it to an email with Outlook or another email web program within Internet Explorer for instance, the file is attached to the email with a special character at the end of the file name that looks like a big dot. If the recipient opens up the email on their computer, even with the FRP client software installed and access to the correct key to open the file, the file cannot be opened due to the special character messing with the file type association within Windows. The user would get a window asking what program they would like to use to open this file since Windows is unsure what file type it is. If the recipient removes this special character at the end of the file name by renaming the file, the file can be opened and appears to have retained the encryption.

       

      The fact that in EEFF this was not an ssue and with FRP the process has changed is a bit concerning to me.  Not only is the file sent out decrypted without creating the policy for the Encryption Options with the blocked processes, but even with the policy in place, the recipient would have to know to rename the file to remove the special character at the end of the file name in order to properly open the file. In my opinon the FRP software should be smart enough to retain the encryption that was previously set locally on the file when it is emailed out as an attachment and the recipient should just be able to either open it directly or save it to their hard drive and open it without any other special steps.

       

      Has anyone else run into this issue and/or have you seen the same type of behavior with the special character appearing at the end of the file name when using the Encryption Options policy with the blocked processes?

       

      Any suggestions or solutions to keep the process as seamless as possible?

       

      Thanks!

        • 1. Re: EEFF to FRP Issue with sending encrypted files via email
          Naveen Chakrapani

          The behavior in FRP 4.3 should be the same as the previous EEFF 4.x versions ? What version of EEFF 4.x were you on before moving to FRP 4.3 ?

          • 2. Re: EEFF to FRP Issue with sending encrypted files via email

            I too am not aware of any changes.

             

            The special char is how EEFF/FRP knows the file is encrypted - you should never see that on a machine with EEFF/FRP installed as it will be hidden. Removing that special char will break the system so don't do it, and even so, if you remove it, you would still have an encrypted file.

             

            The only time you should see the special char, is if you have an encrypted file on a machine not running eeff/frp - ie a machine which does not know how to handle the encrypted files.

             

            Re sending the files decrypted unless there's a bypass rule, this is always how EEFF/FRP has worked - since 2002 onwards.

             

            Outlook attaching a doc to an email is exactly the same as word opening a doc - it's just an application reading a file. So, if you don't use bypass mode, the behaviour will be the same - If the user has the key, the application will get the decrypted data.  As I say, this is how it's worked for over a decade so you should not be seeing anything new here.

             

            I think there must be something else going on in your environment - some other changes must have been made, or perhaps someone changed the policy itself?

            • 3. Re: EEFF to FRP Issue with sending encrypted files via email
              cryptor81

              Hi Naveen/ SafeBoot,

               

              Thank you both for your replies. The EEFF version was 4.2.0.164 prior to moving to FRP 4.3.

               

              I have run across the following KB Article addressing this issue, but the solution provided which I had already tried and mentioned in my original post is not necessarily convenient due to the special character that it puts at the end of the file name:

              https://kc.mcafee.com/corporate/index?page=content&id=KB68994&actp=LIST

               

              The main thing I am trying to accomplish here is to make sure that a file that has been encrypted via FRP locally can then be emailed out by any user while retaining its encryption and can then only be opened by a recipient with the FRP client and access to same encryption key. I have been able to accomplish this using the blocked processes option under the Encryption Options policy I created, but as mentioned, it adds the special character at the end of the file name. If the recipient saves the file onto their local hard drive, the special character is still there and causes Windows to not recognize the file type. Should the recipient remove the special character, they can open the file with no problems. I have been testing this on machines that both have the FRP client software installed and with users that have access to the encryption key used for encryption/decryption of the files. I guess I don't understand why I see the special character on those machines with the FRP client.  I agree with you that I could see this type of behavior if I didn't have the FRP software, but since I do, I would think the FRP software was smart enough to handle the file in the correct manner.

               

              I will review the policy which I have already done several times, but is there anything particular in the policy/settings that I may want to look for that may introduce this type of behavior on a system that has the FRP software installed?

               

              Thanks again!

              • 4. Re: EEFF to FRP Issue with sending encrypted files via email

                if you right-click the file after removing the special char (on a machine with FRP), does FRP tell you it's encrypted still?

                 

                Remember, the special char is ALWAYS at the end of the file name if the file is encrypted, you just can't see it in Windows on an FRP machine. The file char becomes the padlock icon so to speak.

                 

                In the case of emailing an encrypted file to a machine without EEFF, are there TWO special chars perhaps?

                 

                I am also assuming that these are local files you are emailing, not network files?

                • 5. Re: EEFF to FRP Issue with sending encrypted files via email
                  cryptor81

                  SafeBoot,

                   

                  I blew away my policy assignment rule referencing my policy for the Encryption Options for FRP.  I then recreated it with the same settings, then refreshed the policy on my computers with FRP installed.  Looks like if I send the encrypted files via Outlook or Webmail, they retain the encryption, and when I save them with the special character, the special character goes away as it should.  I then check the file is encrypted with the correct key by right-clicking on it and it is.  I can also open the file without any issues now. I think something became flaky with my policy assignment rule, but looks to have been resolved now. 

                   

                  Thank you for all your other input, but I can consider my issue resolved at the moment.