As business use of the Internet was taking off in mid-1998 I began hearing this consistent message from IBM AS/400 users: “We need encryption to protect our data as it moves over the Internet.” I only needed to hear this a few times before I began looking at incorporating encryption options into our file transfer applications.
My research included talking to a handful of encryption vendors, before finding an application called “Pretty Good Privacy,” or PGP. The application was the work of Phil Zimmermann and a small cohort of fellow off-the-map developers. I researched Phil a bit before contacting him, and — uh oh — I found he had been in trouble with the US government back when encryption was considered a “munition.” So it was with a little hesitation that I decided to place a call to this “outlaw” programmer.
By this time, the controversy over Phil’s activities had died down, and many of the restrictions on encryption had been relaxed. I found it surprisingly easy to get his phone number, get Phil on the phone, and see what he thought about using PGP on large systems.
We had a good conversation about PGP and its prospects for becoming a commercial standard for data protection. Phil was very helpful and we discussed some of the technical issues in porting PGP to the AS/400. He encouraged me to take the leap into the PGP project, and gave me referrals to the development team in charge of the commercial version of PGP. That call and his encouragement were crucial to our efforts over the next 10 years to bring PGP encryption to large IBM platforms.
After some twists and turns, and a few months of laboring in the trenches, we released the first version of PGP for the AS/400. The port to the AS/400 turned out to be a really big challenge. The C compiler was in its infancy, and we struggled with its limitations. And the ASCII to EBCDIC conversions were a nightmare. But we got the product released in 1999. It was very popular and remains so today. We now have hundreds of customers using PGP to protect their data.
PGP is now the de facto standard for whole file encryption in eCommerce. It is deployed by banks, insurance companies, medical suppliers, payroll servicers, and a wide variety of other organizations. Almost every organization on planet Earth deploys PGP to protect sensitive data. Phil’s vision of PGP becoming a widely accepted method of protecting data has become a reality.
Of course, PGP has been through some changes over the years. New encryption algorithms have been added such as AES and Elliptic Curve Cryptography. The product found a new home at PGP Corporation, and has undergone steady development since then. We have a great relationship with the folks at PGP, and many of them have been working with the product from the first days.
PGP Corporation recently completed a FIPS-140 certification of the PGP technology, and this was an important step. As we watch the evolution of security standards, I believe that independent certification by NIST will be crucially important in the months and years ahead. I know from personal experience that certification is hard to do and demands a deep commitment on the part of an encryption vendor. But there is no substitute for the rigor and discipline that it requires.
Here at PTSS we continue to incorporate PGP into new solutions. It’s a rock-solid platform on which to build. I’m happy to continue working with PGP Corporation, and you’ll be hearing from us soon about some of our new developments that incorporate PGP encryption.
After all these years, I’m grateful for Phil’s words of encouragement back in 1998. And am reminded to never underestimate what a few encouraging words can do. Thanks Phil!
I recently returned from the 2009 RSA conference in San Francisco, and found it a worthwhile venue for getting the true pulse of the industry. Despite the current economic difficulties it is clear that businesses are still concerned about security and are investing in data leak protection (DLP), intrusion detection, scanning, and system log management. Surprisingly, however, at this year’s show there were very few developments on the encryption front. And in a way, I consider this silence as significant as “the dog that didn’t bark” in a famous Sherlock Holmes story.
For those unfamiliar with “the dog that didn’t bark,” it refers to a Sherlock Holmes story in which a dog’s silence (a non-event) was a critical clue to solving the crime. Similarly, I find the industry’s near silence on encryption to be significant. You see, encryption (and related key management technologies) are necessary tools to fight data theft. Yet the industry has seen a reduction in the number of encryption and key management vendors through consolidation and acquisition. What this near silence signifies however, remains to be seen.
One development that is generating plenty of noise is that the bad guys are getting much better at what they do. The days when a break-in was mostly an opportunity for bragging rights is gone. The attacks now are much more sophisticated and are often well-hidden from security software. The intent is to steal sensitive information and to use it for identity theft and fraud. The result is that we continue to see on-going losses of sensitive information, and the threat is getting harder to detect and prevent.
I remain convinced that until encryption becomes woven into our business applications we will continue to suffer continued losses of sensitive data. I’m not naïve about encryption as the solution – encryption is not a panacea to the data theft problem. It is not sufficient in itself to protect data. But it is a necessary component of a data protection scheme. IDS, DLP, and logging will never provide adequate protection by themselves. Properly implemented encryption has to be a part of any data protection scheme.
On a personal note, I hope RSA returns to the Moscone Center for the next RSA in 2010. The South of Market Area in San Francisco is vibrant and has left its urban decay behind. Great restaurants and cafes are abundant in the area and this is an inviting part of a beautiful city. I’m sure we’ll be exhibiting again next year with some interesting news!
Patrick
Like many of us, your company is probably looking for ways to reduce costs and increase revenues during these tough economic times. For those of you using the IBM i platform, one way to achieve both of these goals is to deploy Web services and XML processing directly on your Power System. XML has rapidly become the de facto standard for data interchange between customers, vendors, and web-based services. It’s much easier to deploy than Electronic Data Interchange (EDI) which often requires expensive software, VAN contracts, and per-document fees. And as a bonus, XML provides built-in encryption to protect sensitive data and satisfy compliance rules.
When the opportunity arises and you need to deploy XML and web services, it’s crucial to integrate with your existing ERP and CRM applications and to get it up and running fast. There are a few critical factors you should look for in a good IBM i web services solution. A successful IBM i web services solution should:
• Be affordable to deploy
• Maximize your RPG and Cobol developer skills
• Solve the complex communications requirements of web services
• Use strong encryption to protect your sensitive data
Many of our customers are using the Alliance XML/400 product to meet the challenges of XML and web services. With a built-in XML-to-DB2 mapping application, secure web communications, and built-in encryption, there is no web service integration project too tough for Alliance XML/400. Here are some examples of recent successful customer projects:
• IBM i order management integration with web-based shopping cart for Weaver Popcorn.
• Lawson purchasing integration with IBM i ERP solution for Bed Bath & Beyond.
• IBM i customer loyalty program integration with RightNow CRM for Bass Pro.
• IBM i integration with Microsoft SharePoint servers for Williams-Sonoma and Pottery Barn.
These projects helped companies reduce costs, increase customer loyalty, and bring on new customers and new sources of revenues.
Alliance XML/400 has stood the test of time and has a rich set of capabilities. It handles the technology challenges that are tough for standard RPG and Cobol application developers. These include Proxy server negotiation, WebDAV file transfer, encryption, Base64 encoding, XML to DB2 translation, and HTTP and HTTPS client and server applications. All of this is available without a requirement for IBM Websphere, the Apache server, expensive hardware upgrades, or time-consuming API programming.
You can read more about Alliance XML/400 here.
I hope you’ll find that by knowing more about XML for System i you’ll be able to profit from the next business opportunity that comes your way.