AES 256 Encryption Client Issue

SimonTemplar

We are currently updating our security policy which states that all documentation sent externally to clients must be encrypted using 256 AES. That seems straightforward but we have run into the following snags:

We had planned to encrypt using WinZip but our clients don't want to have to install third party software.

I suggested I develop a small .NET application that we would use to encrypt and they would use to decrypt but they don't want to install software of any kind. I said they won't have to "install" it as such, just click the exe but that is a no go.

Unfortualtely our website does not have the ability for us to upload documents for download.

I could use some self-extracting archive but these files are sent by email and I'm concerned the antivirus software on both sides will disallow that attachment.

Can anyone think of any alternatives (either development or existing solutions)?

Thanks

CreepingDeath

Host all the documentation on a secure FTP site, and the clients will have to pull the documentation down over a secure connection.

Browser support FTP, so you just need to e-mail the client the FTP link and their username/password.

Graham

You're quite right, anti-virus software will most likely causes problems with any attachments where it cannot scan the contents. You could ask the recipients to white-list attachments from specific senders.

You're also likely to have problems with an FTP approach if your recipient is behind a firewall. Most corporates block FTP access by default.

CreepingDeath

Graham wrote: »

Most corporates block FTP access by default.

Then host it on a secure web server (Https), with authentication access control.

Graham

CreepingDeath wrote: »

Then host it on a secure web server (Https), with authentication access control.

Still might cause problems if the internet connection runs through a gateway like Web Marshal. Downloads are cached and scanned for threats, unrecognised attachments (e.g. encrypted) usually get eaten by the gateway.

I'm not deliberately trying to be awkward here, just faced the same situation as the OP at some point in the past.

SimonTemplar

Graham wrote: »

Still might cause problems if the internet connection runs through a gateway like Web Marshal. Downloads are cached and scanned for threats, unrecognised attachments (e.g. encrypted) usually get eaten by the gateway.

I'm not deliberately trying to be awkward here, just faced the same situation as the OP at some point in the past.

Thanks Graham.
What solution did you implement for your situation, if any.


Can anyone suggest the best secure FTP site with 256 AES perferrably with an uploading API / web service.

Graham

After much to-and-fro debate, exceptions to the mail scanners were put in place to permit encrypted mail between specific sender/recipient pairs.

Your situation is slightly more complicated if the recipients won't consider installing any additional software.

I think you may have to approach the problem from a less technical perspective. Can you put any political pressure on the recipients to assist in finding a secure compromise solution. How about giving them 2 potential solutions:

1) They will be sent the encrypted emails using X as a solution. Leave it down to them to procure/install X.
2) Explain that the only alternative is unencrypted emails. Suggest they talk to their Data Protection officer and/or the data protection registrar. Ask that their data protection officer sign-off (In writing) on this information being transferred in the clear and that such information is received by them at their own risk.

In the end, option 2 usually forces the decision above the heads of anyone that's being awkward.

stevenmu

If you're going to FTP route, you will need to clarify in your policy that transmission of the document is encrypted, rather than the document itself.

Also, will a regular web browser support FTP with 256 AES?

stevenmu

Oh, and I believe Acrobat 9+ uses 256-bit AES for encrypting password protected PDFs. Your clients still require some PDF reader software (that supports password protected PDSs), but that's something they are reasonably likely to have.

SimonTemplar

Graham wrote: »

After much to-and-fro debate, exceptions to the mail scanners were put in place to permit encrypted mail between specific sender/recipient pairs.

Your situation is slightly more complicated if the recipients won't consider installing any additional software.

I think you may have to approach the problem from a less technical perspective. Can you put any political pressure on the recipients to assist in finding a secure compromise solution. How about giving them 2 potential solutions:

1) They will be sent the encrypted emails using X as a solution. Leave it down to them to procure/install X.
2) Explain that the only alternative is unencrypted emails. Suggest they talk to their Data Protection officer and/or the data protection registrar. Ask that their data protection officer sign-off (In writing) on this information being transferred in the clear and that such information is received by them at their own risk.

In the end, option 2 usually forces the decision above the heads of anyone that's being awkward.

We are dealing with 100s of clients. Some will have no problem adapting to our needs, others (probably a minority) will have an issue. Sadly, we need a blanket procedure for everyone.

The 256 AES requirement is entirely on our side. They are not requesting it.

stevenmu wrote: »

If you're going to FTP route, you will need to clarify in your policy that transmission of the document is encrypted, rather than the document itself.

Also, will a regular web browser support FTP with 256 AES?

Given the number of docs involved, manually uploading each one is not feasible unless they support batch upload.

I do like the idea of uploading the docs to a secure site and simply providing the clients with the url and login details (but as you said, that would have to conform with our data policy).

stevenmu

Oh, I just saw you're talking about 100s of customers, password protected PDFs probably isn't a runner so

stevenmu wrote: »

Oh, and I believe Acrobat 9+ uses 256-bit AES for encrypting password protected PDFs. Your clients still require some PDF reader software (that supports password protected PDSs), but that's something they are reasonably likely to have.

SimonTemplar

stevenmu wrote: »

Oh, and I believe Acrobat 9+ uses 256-bit AES for encrypting password protected PDFs. Your clients still require some PDF reader software (that supports password protected PDSs), but that's something they are reasonably likely to have.

I looked into that. We currenly have Acrobat 8. I believe Acrobat 10 supportts 256.

We have no problem purchasing an updated version of Acrobat but my concern is time. Is it possible to automate Acrobat to open each PDF in a particular folder and save it with 256 encryption. Each document batch contains 500 files so it isn't feasible to do this manually. Is this can be automated, that could be the solution. Does Acrobat provide an API or library?

ChRoMe

SimonTemplar wrote: »

I looked into that. We currenly have Acrobat 8. I believe Acrobat 10 supportts 256.

We have no problem purchasing an updated version of Acrobat but my concern is time. Is it possible to automate Acrobat to open each PDF in a particular folder and save it with 256 encryption. Each document batch contains 500 files so it isn't feasible to do this manually. Is this can be automated, that could be the solution. Does Acrobat provide an API or library?

I'm sure there are command line tools for doing it, in conjunction with some shell scripting I'd say you could automate it without too much hassle.

Blowfish

What about just looking for a 3rd party complete solution like Accellion's Secure File Transfer?

Talisman

DropBox uses both SSL and AES-256 bit encryption.

amen

I'm curious but why are you encrypting documents that you are sending to clients ? What exactly is in the documents that requires encryption and what do your clients do with the documentation ?

SimonTemplar

The documents are financial statements.

The 256 encryption policy is determined by our parent company and we have to follow it.

amen

So if they are financial statements are you
A: emailing the statements to individual clients
B: emailing a client list to a client i.e an Agency/Broker which them forwards them to the true client ?

If A then why not just have secure login site where the client can access the statement ? That way you control the access, have an audit trail etc and technically the statement never leaves your company unless it is printed by an authorised user.

Now if its B then its more tricky but I would still be leaning toward a secure site.

Emailing secure documents seems like an a problematic approach and will lead to extra support calls.

StickyMcGinty

SimonTemplar wrote: »

API or library?

For PDF automation you can use managed .NET libs like Aspose.PDF to do that for you. Sample HERE

There's a tonne of PDF libs I'm sure there might be a free one that will do what you want, I'm just saying we've used the above and are happy with it

you still might have an issue with the management of passwords/keys though - i.e. do you use one password for all? etc