Note: While this might sound self-serving, given the nature that free and open-source Java crypto-code is involved, I thought the forum might find this posting useful. The moderators, of course, always have the discretion to modify/delete the posting if they deem it to be inappropriate. Thanks.
The "Regulatory Compliant Cloud Computing (RC3)" web-application architecture we devised last year for secure cloud computing is gaining some visibility and momentum in the press:
1) InfoQ, a site for application architects and developers, published an RC3 article in December 2011: [http://bit.ly/rc3infoq|http://bit.ly/rc3infoq]
2) OWASP, an international web-application security project accepted the RC3 paper for their AsiaPac 2012 AppSec conference in Sydney, Australia where I will be presenting next month: [http://bit.ly/rc3owap|http://bit.ly/rc3owap]
3) The Information Systems Security Association published an article last week in their monthly ISSA Journal which goes out to 10,000+ security professionals in 70 countries: [http://bit.ly/rc3issa|http://bit.ly/rc3issa]
4) IBM published the article last week on their world-wide developerWorks website for application developers. (From their site: Four million developers, IT professionals, and students in 195 countries use developerWorks each month to learn about advances in IT and open standards, develop skills, solve problems, and work collaboratively with experts and peers.): [http://ibm.co/rc3dw|http://ibm.co/rc3dw]
Starting next week, we will be releasing FOSS applications built using the RC3 architecture. They are intended to show how RC3 can be used to build viable/useful web-applications that can leverage the Cloud without compromising data-security.
- CryptoCabinet - a web-application to encrypt and transfer files to AWS, Azure, Eucalyptus, SAN/NAS and local drives while preserving keys securely in compliance with security regulations;
- CryptoCommerce - a web-application demonstrating how an e-commerce application can use public/private clouds for transactions while being PCI-DSS compliant; and
- CryptoPostBox - a web-application to send encrypted e-mail to anyone on the internet (without the need for digital certificates, PGP/GPG keys, etc.).
All applications use the CryptoEngine ( [http://www.cryptoengine.org|http://www.cryptoengine.org] ), for underlying cryptographic/cloud operations and the StrongAuth KeyAppliance for key-management. The CryptoEngine FOSS has been available for more than 4 months on sourceforge.net. All these applications are licensed under the LGPL.
Most people on this forum are trying to solve the problems these free tools solve; perhaps they might find it useful to re-use these libraries rather than reinvent the wheel. Hope you find this useful.
On the surface, "CryptoPostBox - a web-application to send encrypted e-mail to anyone on the internet (without the need for digital certificates, PGP/GPG keys, etc.). " sounds a lot like 'snake oil' so I have been trying, without success, to find some description of the fundamentals of it's operation. Can you point me to a reference that summarizes the approach ( I may look at the detail later but for the moment I just need an outline ) ?
I should have known better than to just put out a "marketing" posting on this forum; apologies to all.
First, a clarification: the three Crypto* products are not yet released; we're planning to release CryptoCabinet today or tomorrow; the CryptoCommerce in the next 2 weeks and the CryptoPostBox a few weeks after that.
That said, here is the capability we're working on for the CryptoPostBox: it is a Business-to-Consumer (B2C) and Consumer-to-Business (C2B) solution; definitely not a C2C solution (where other existing tools are a better fit). It is also not a B2B solution where S/MIME may be a better fit (but it could be used for B2B if the policies and access-control is managed properly). The technical architecture works as follows:
1) An enterprise key-management infrastructure (EKMI) is a prerequisite in the Business's intranet; this infrastructure should be capable of generating and managing million/billions of cryptographic keys, depending on the business requirements (our KeyAppliance meets this requirement);
2) The StrongKey CryptoEngine (SKCE) (FOSS) has the ability to encrypt files (any-type-any-size) using keys that are escrowed in the EKMI and storing them in the Cloud or local/network storage - (this PDF file provides a quick 3-5 minute introduction of the SKCE: http://www.cryptoengine.org/images/pdf/skce-intro-v1.3.pdf);
3) The CryptoPostBox (CPB) (also FOSS) will be a web-application that will allow authorized resources inside a Business to specify one or more Consumers' e-mail address(es) and provide the message. The CPB will use the SKCE to generate a key, escrow the key with the EKMI, encrypt the message, store it somewhere accessible to the CPB, generate a unique URL and send the target recipient(s) the unique URLs to download the message. The URL will lead to a page that, after using a CAPTCHA to eliminate robotic searches, will allow the user to download the message - which will be decrypted by the SKCE on the fly - over SSL.
4) A feature we're considering adding, is to allow the Consumer to download the encrypted message and keep it on their local PC. The Business could then offer a service - for a fee or free; its upto them - that would allow authenticated customers to upload the file to the Business' CPB and decrypt it on the fly.
5) The CPB is NOT intended to work like S/MIME or GPG/PGP; the Business is always in control of the symmetric key (which it can choose to delete based on its own policies and business requirements) and data is always in an encrypted state until the user views the message. Of course, if the user copies the message into a document and saves it in plaintext, that is their business.
6) Consumers may send encrypted messages to target recipients in the Business by going to a web-form and filling out the form. The servlet behind that web-form will use the SKCE to encrypt the message, store it somewhere accessible to the CPB and send a plaintext message to the recipient to download the decrypted message to their PC.
7) While the plaintext notification communications from the CPB can, obviously, be integrated to MUAs like Outlook or Thunderbird, we don't see that as our competency; others FOSS developers may choose to build on our work and provide that added value if they choose to.
8) Internet-connectivity is always required for this capability to work.
Thanks for that Ashad. I will have to think about CryptoPostBox to make sure I understand the concept. At the moment I don't see much of a technical advantage of CryptoPostBox over GPG/PGP but I don't yet have enough of a grasp of CryptoPostBox to make an informed judgement.
I suppose one big advantage is going to be political. I have tried to use GPG and PGP within a company but have found that the average employee does not see email as insecure so most of the time it is not used. I can see that using a CryptoPostBox type of application a company can force employees to encrypt emails. Also, I'm not a fan of key escrow but I can see that it might be an advantage in a B2B role such as this.
At the moment I already have 2 major programming projects on the go and what with my Bridge commitments, minimal gardening and some building work I don't don't have much free time. If I do get any free time, when it is released I will download CryptoPostBox and try to spend some time working with it but don't hold your breath.
A free and open-source web-application - StrongKey CryptoCabinet - was released today for General Availability. The CryptoCabinet is built using the RC3 architecture and can be used to encrypt files and store them in public or private clouds (or SAN/NAS devices) while storing cryptographic keys securely outside the cloud on the StrongAuth KeyAppliance. The CryptoCabinet uses the StrongKey CryptoEngine (http://www.cryptoengine.org - also FOSS) for its underlying cryptographic functions and cloud communications.
Details can be found at http://www.cryptocabinet.org.