I have a client who is in need of a file based encryption / decryption application to be used between Linux / Windows 2003 Server. The goal is to have a single file compressed nightly on a linux platform and secured using a script, transmitted over FTP, decrypted on the Windows 2003 server and available for other import routines such as SSIS, etc.
The file can remain unencrypted on each end after transport, the desire is mainly to keep the file secure during transport. Firewall rules and the fact that IIS6 doesn't support SFTP eliminate SFTP as an option. Simplicity is the primary focus here, so complex security options or heavyweight libraries cannot be used.
You could try GnuPG, it's cross platform and since you are only sending files internally you don't really need a certificate signed by a big-name certificate authority.
Also you can use our OpenPGP task for SSIS when you need to load the protected data into SSIS.
You could look at PGP:
http://www.pgpi.org/doc/overview/
http://www.pgpi.org/products/pgp/versions/freeware/
http://www.pgpi.org/doc/
To GnuPG I would add Thawte (or similar) s/mime keys for email.
GnuPG has executables for every major platform and most email clients support s/mime keys for encryption.
Try R10Cipher.
Cross Platform,
384 Bit,
Handles Text and Files,
Very Simple to use and inexpensive
http://www.r10cipher.com
Disclaimer: It's produced by my company, Arten Science.
Related
I'm working on creating a license manager that will be deployed to our customers. Without going in to many specifics, we haven a number of parameters that we configure in a license file which is then encrypted and placed on the client server. The license manager decrypts this file and reads the values. Currently this is all done using line by line Triple-DES (as in.. each line is encrypted, separately..). I'm working on re-writing the entire thing in NodeJS.
The goal is to be able to encrypt a plain text license file and distribute that file to the customer server. The customer server will be running a license manager NodeJS application that needs to be able to decrypt the license.
It looks like private/public key encryption might be the way to go - but will the customer be able to use the key that we distribute with the license manager to encrypt their own license file?
It looks like the route I should have been looking at is digital signatures and not encryption.
In both ways it's possible to find way to create own license file. Because you will keep the key to decrypt (or public key to check signed license) in to the code. So someone can find/replace this key and replace it with own. And then create own license file with own encrypted/signed license.
You can avoid this by create online service which will be called each time someone start the product to check the license. This also can be mitigated, but IMHO not very easy
I'm after some concrete advice on how best to prevent (or at least deter) unauthorised software upgrades on an embedded system. It doesn't need to be bullet-proof and we can assume for now that the system itself is sufficiently locked down so that no-one can get unauthorised access to it.
My plan is to basically have an installer process running on the system which would receive update packages from anywhere but that could ensure those packages came from a trusted source (i.e., me) before attempting to install them.
In simple form, the update package would have the actual installation package, plus a matching digital signature that could only be generated by myself. Moreover, the signatures would be purely self-generated with no external authorities involved.
So these are my thoughts on the possible process:
Generate a private/public key pair and distribute the public key along with the embedded system itself.
When creating a software install package, pipe the contents of the package (or an MD5 of the package) through a signature generator using our private key.
Distribute the software install package along with that signature.
Have the installer check the signature against the software install package (using the public key it already has) and only install if there's a match.
If anyone can find any problems with this scheme, I'd appreciate the details, along with any specific advice on how to avoid them. In addition (though this is not the primary purpose of the question), any advice on tools to generate the keys would be appreciated.
I do not see any apparent problems with your solution. I can suggest improvements that you may have already taken into account
If the embedded software is sufficiently locked, it is not necessary to take additional measures to protect the integrity of the public key distributed with the software (e.g. by signing the installer itself and obfuscate, that could be a headache)
I've considered a TLS connection to download the updates, but it would not really needed, because packages are going to be protected with a digital signature
I suggest encapsulating the public key in an X509 certificate. This way you can control the period of validity and even a possible revocation if the private key has been compromised. In this case you will need a hierarchical Certificate Authority, with a root certificate that issues the signing certificates. Include in the truststore of the installer the public part of the root certificate. Then using a different signing certificate after expiration/revocation will be transparent to installer.
The root certificate has a long duration and a large key size (and should be conveniently secured), and the signing certificates have a shorter duration and can use a smaller key.
With this CA you could also generate a TLS certificate if you need some additional service: e.g check available updates. In this case include the certificate in the truststore of the installer to avoid man-in-the-middle attacks (SSL-pinning).
You can sign the full distribution or a hash. It does not affect security (see https://crypto.stackexchange.com/questions/6335/is-signing-a-hash-instead-of-the-full-data-considered-secure) but do not use MD5 because has extensive vulnerabilities. Use a SHA-2 function.
To generate the keys you can use openssl in command line or use the GUI application KeyStore-Explorer
I must see the traffic from an android phone to a secure server using wireshark on Windows.
All packets are encrypted with ssl but i don't have the key, how can i find it?
Thanks
The key will be on the server. It depends on what software the server is running as to where the key will be stored or in what format. If it's an Apache server, then look in the ssl.conf file for SSLCertificateKeyFile. (Depending on the configuration, this may actually be stored in a different configuration file, you can grep for the string.)
Once you have the file, you can add it to Wireshark under the "SSL" protocol preferences. For more, see the SSL page on the wireshark wiki.
If you only have access to the client, it's possible to decrypt traffic using the pre-master secret, but it's a lot more inconvenient and you generally need to rework your client software to output it (and then it's only useful for that specific session; and if you have that, you might as well just have the client log its traffic in most cases). If this is your case, and you have a mechanism to get the software to output its pre-master secret (or can modify the software to do so), I can update the answer with more on that scenario. But if at all possible, avoid it and use the server's private key.
If you have lack privileged access to the client or the server, this is by-design not a solvable problem.
I am looking for an encrypted version control system . Basically I would like to
Have all files encrypted locally before sending to the server. The server should never receive any file or data unencrypted.
Every other feature should work pretty much the same way as SVN or CVS does today.
Can anyone recommend something like this? I did a lot of searches but I cant find anything.
You should encrypt the data pipe (ssl/ssh) instead, and secure the access to the server. Encrypting the data would force SVN to essentially treat everything as a binary file. It can't do any diff, so it can't store deltas. This defeats the purpose of a delta-based approach.
Your repository would get huge, very quickly. If you upload a file that's 100kb and then change 1 byte and checkin again, do that 8 more times (10 revs total), the repository would be storing 10 * 100kb, instead of 100kb + 9 little deltas (let's call it 101kb).
Update: #TheRook explains that it is possible to do deltas with encrypted repository. So it may be possible to do this. However, my initial advice stands: it's not worth the hassle, and you're better off with encrypting the ssl/ssh pipe and securing the server. i.e. "best practices".
It is possible to create a version control system of cipher text. It would be ideal to use a stream cipher such as RC4-drop1024 or AES-OFB mode. As long as the same key+iv is used for each revision. This will mean that the same PRNG stream will be generated each time and then XOR'ed with the code. If any individual byte is different, then you have a mismatch and the cipher text its self will be merged normally.
A block cipher in ECB mode could also be used, where the smallest mismatch would be 1 block in size, so it would be ideal to use small blocks. CBC mode on the other hand can produce widely different cipher text for each revision and thus is undesirable.
I recognize that this isn't very secure, OFB and ECB modes shouldn't normally be used as they are weaker than CBC mode. The sacrifice of the IV is also undesirable. Further more it isn't clear what attack is being defended against. Where as using something like SVN+HTTPS is very common and also secure. My post is merely stating that it is possible to do this efficiently.
Why not set up your repo (subversion, mercurial, whatever) on an encrypted filesystem, and use ssh only to connect?
Use rsyncrypto to encrypt files from your plaintext directory to your encrypted directory, and decrypt files from your encrypted directory and your plaintext directory, using keys that you keep locally.
Use your favorite version control system (or any other version control system -- svn, git, mercurial, whatever) to synchronize between your encrypted directory and the remote host.
The rsyncrypto implementation you can download now from Sourceforge not only handles changes in bytes, but also insertions and deletions.
It implements an approach very similar to the approach that that "The Rook" mentions.
Single-byte insertions, deletions, and changes in a plaintext file typically cause rsyncrypto to make a few K of completely different encrypted text around the corresponding point in the encrypted version of that file.
Chris Thornton points out that ssh is one good solution; rsyncrypto is a very different solution. The tradeoff is:
using rsyncrypto requires transferring a few K for each "trivial" change rather than the half-a-K it would take using ssh (or on a unencrypted system). So ssh is slightly faster and requires slightly less "diff" storage than rsyncrypto.
using ssh and a standard VCS requires the server to (at least temporarily) have the keys and decrypt the files. With rsyncrypto, all encryption keys never leave the local computer. So rsyncrypto is slightly more secure.
SVN have built-in support for transferring data securely. If you use svnserve, then you can access it securely using ssh. Alternatively you can access it through the apache server using https. This is detailed in the svn documentation.
You could use a Tahoe-LAFS grid to store your files. Since Tahoe is designed as a distributed file system, not a versioning system, you'd probably need to use another versioning scheme on top of the file system.
Edit: Here's a prototype extension to use Tahoe-LAFS as the backend storage for Mercurial.
What specifically are you trying to guard against?
Use Subversion ssh or https for the repo access. Use an encrypted filesystem on the clients.
Have a look at GIT. It supports various hooks that might do the job. See, git encrypt/decrypt remote repository files while push/pull.
Have you thought of using Duplicity? It's like rdiff-backup (delta backups) but encrypted? Not really version control - but maybe you want all the cool diff stuff but don't want to work with anyone else.
Or, just push/pull from a local Truecrypt archive and rsync it to a remote location.
rsync.net has a nice description of both - http://www.rsync.net/resources/howto/duplicity.html
http://www.rsync.net/products/encrypted.html
- apparently Truecrypt containers still rsync well.
Variant A
Use a distributed VCS and transport changes direct between different clients over encrypted links. In this scenario is no attackable central server.
For example with mercurial you can use the internal web server, and connect the clients via VPN. Or you can bundle the change sets and distribute them with encrypted mails.
Variant B
You can export an encrypted hard drive partition over the network and mount it on the client side, and run the VCS on the client side. But this approach has lot's of problems, like:
possible data loss when two different clients try to access the VCS at the same time
the link itself must be secured against fraudulent write access (when the partition is shared via NFS it is very likely to end with a configuration where anyone can write to the shared partition, so even when there is no way for others to read the content, there is easily a hole to destroy the content)
There might be also other problems with variant B, so forget variant B.
Variant C
Like #Commodore Jaeger wrote, use a VCS on top of an encryption-aware network file system like AFS.
Similar to some comments above, a useful workaround may be to encrypt&zip the whole repository locally and synchronize it with the remote box. E.g. when using git, the whole repository is stored in directory '.git' within the project dir.
zip/encrypt the whole project dir
upload it to a server (unsure if handling .git alone is sufficient)
before you continue working on the project download this archive
decrypt/unpack and sync with git (locally)
This can be done with a simple shell line script more comfortable.
pro: You can use whatever encryption is appropriate as well as every VCS which supports local repositories.
cons: lacks obviously some VCS features when several people want to upload their code base (the merge situation) - although, perhaps, this could be fixed by avoiding overwrite remotely and merging locally (which introduces locking, this is where the nightmare starts)
Nevertheless, this solution is a hack, not a proper solution.
Based on my understanding this cannot be done, because in SVN and other versioning systems, the server needs access to the plaintext in order to perform versioning.
Source safe stores data in Encrypted files. Wait, I take that back. They're obfuscated. And there's no other security other than a front door to the obfuscation.
C'mon, it's monday.
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.