by Klaus Heinrich Kiwi, LTC Security team
The openCryptoki project, a PKCS#11 provider for Linux with support for software and hardware tokens, has released new versions for both the openCryptoki code itself as well as for it’s associated library, libica.
- Libica-2 is a major cleanup from the previous versions. It has a new API and supports software fall-back (OpenSSL) when no Crypto hardware is present. The current version (2.0.2) has bug fixes and improved code examples.
- OpenCryptoki 2.3.0 includes support for Libica-2 and has a number of bug fixes and minor improvements
OpenCryptoki is the most common way that PKCS#11-enabled applications (including Java JCE aplications) can exploit cryptographic hardware in a Linux environment.
The Trusted Computing Group (TCG) Trusted Platform Module (TPM) specification v1.2 is now officially ISO/IEC standard 11889. The TCG has published a press release commemorating the event and the TCG president Scott Rotondo has written a blog entry on the importance of this accomplishment.
Congratulations and thanks to the TCG members who made this possible!
By Bryan Jacobson, Linux Technology Center.
Tyler Hicks (from our team) recently attended the 5/25-29 Ubuntu Developers Summit for Karmic Koala in Barcelona, Spain.
Some of Tyler’s observations on Security topics:
- There are quite a few eCryptfs users out there and they are generally happy with the version shipped in Jaunty. Most were using the encrypted home feature, but some wanted more flexibility and had custom setups.
- eCryptfs encrypted swap is on the roadmap for Karmic.
- Michael Rooney has been working on graphical applications to compliment some of the eCryptfs userspace tools that are currently bound to the command line.
- Tyler held an eCryptfs roadmap talk about future eCryptfs features: eCryptfs on top of popular network filesystems, improved key management, and asking for someone interested in completing the eCryptfs GPG key module.
Some general observations from Tyler:
- Ubuntu would like to be the premier guest available in Amazon EC2.
- Ubuntu users will soon have a daily build of the virtualization stack available, which is a big win for both the upstream developers and the users.
- Dustin Kirkland http://blog.dustinkirkland.com/ gave a talk on leveraging the cloud for data center power savings.
- The Ubuntu kernel team committed to removing non-upstream kernel code that no one is using anymore.
See the whole story on Tyler blog at: http://blog.tyhicks.net
AMTU 1.07 has just been released on ATMU’s Sourceforge home. This release incorporates a patch from Joy Latten to add IPv6 interfaces to the list of interfaces probed to test networking devices. It also contains a small fix to the memory separation routine.
MD5SUM: 8858a47c667ffc4af840d72d8ced6605 amtu-1.0.7.tar.gz
SHA1SUM: 7f56a17ca616b6dc23564894c8503e5c5c75aa06 amtu-1.0.7.tar.gz
amtu is a small and simple machine check that is required for Common Criteria certification. It was originally released in 2003. You can find it at https://sourceforge.net/projects/amtueal/.
By Debora Velarde, IBM Linux Technology Center
Someone recently pointed me to a study on the Open Source Trusted Computing Software Stack which was sponsored by The German Federal Office for Information Security (BSI). The study titled “Introduction and Analysis of the Open Source TCG Software Stack TrouSerS and Tools in its Environment” was performed by Sirrix AG security technologies. The study is available in English from the BSI web site. Since the study was published on the BSI site a year ago, some of the information is a little outdated. But it is still a good read for anyone trying to understand the different components that make up the Trusted Computing Software Stack and the relationship between the different components.
The study covers many of components that I was already familiar with: TrustedGRUB [1], GRUB-IMA [2], the Linux TPM Device Driver [3], TrouSerS [4], TPM Tools [5], and the OpenSSL TPM Engine [6]. However, the study also covered some items that I hadn’t known about prior to reading the study: the Open Secure Loader (OSLO) and the TPM Manager. OSLO is a security enhanced bootloader that uses the Dynamic Root of Trust for Measurement [7]. TPM Manager is a graphical user interface for managing the TPM which Sirrix AG helped to develop [8]. One item the study does not cover is Hal Finney’s Privacy CA which Emily blogged about back in January of 2008. For each component included in the study, it provides an overview, some install and configuration information, and an analysis of the quality of the implementation. The quality analysis includes details such as: implementation language, lines of code, whether the code is well commented, available documentation and support such as mailing lists.
In the “Compliance and Interoperability” chapter, the study takes a look at each of the components focusing on their compliance with respect to different specifications. Next, the study includes results from testing the components interoperability with SELinux [9], the Xen hypervisor [10], and the Turaya security kernel [11]. If you’ve never heard of the Turaya security kernel, you’re not alone. Information about Turaya is available on the Sirrix AG web site.
In the final chapter, the study makes some conclusions about the Open Source Trusted Computing Software Stack. It states that “the most important building blocks” are “available and robust enough to be used in a wide variety of security-critical services and applications”. The study continues to note that there is currently no application that actually takes advantage of this trusted computing technology. The study also concludes that the results from the interoperability testing with SELinux, Xen, and Turaya, are “high enough to realize TC-enabled applications on top of them.” Finally, the study closes by discussing some open issues including suggestions for improvement.
Related Links:
[1] TrustedGRUB: https://sourceforge.net/projects/trustedgrub
[2] GRUB-IMA: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html
[3] Linux TPM Device Driver: now part of the Linux kernel http://kernel.org/
[4] TrouSerS: https://sourceforge.net/projects/trousers/
[5] TPM Tools: https://sourceforge.net/projects/trousers/
[6] OpenSSL TPM Engine: https://sourceforge.net/project/showfiles.php?group_id=126012&package_id=165637
[7] Open Secure LOader: http://os.inf.tu-dresden.de/~kauer/oslo/
[8] TPM Manager: https://sourceforge.net/projects/tpmmanager/
[9] SELinux: http://www.nsa.gov/research/selinux/index.shtml
[10] Xen: http://www.xen.org/
[11] Turaya: http://www.sirrix.com/content/pages/50580.htm
By: Bryan Jacobson (bryan.jacobson@us.ibm.com) As always, the following are my personal opinions.
“Product X”
I recently heard about an authentication product, let’s call it “Product X”. According to their website:
Product X . . . implements the equivalent of a “one-time pad” system – the most secure communication possible.
Product X uses applied physics to defeat all known Internet authentication threats.
Sounds good, maybe too good. Can we trust it?
Cryptographic Snake Oil
Serge Hallyn introduced me to the term “cryptographic snake oil”, which is explained at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html:
Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security.
Why “snake oil”? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor’s claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just about any ailment that a potential customer could have. Listening to the claims made by some crypto vendors, “snake oil” is a surprisingly apt name.
The snake-oil-faq is a fun website with a lot of information. Regarding “one-time-pads” it says:
A vendor might claim the system uses a one-time-pad (OTP), which is provably unbreakable.
Snake oil vendors will try to capitalize on the known strength of an OTP. But it is important to understand that any variation in the implementation means that it is not an OTP and has nowhere near the security of an OTP.
What are One-time-pads, and why are they “unbreakable”?
A One-time-pad is a key as long as the message. Each byte of the OTP is generated with an unpredictable random process.
The sender and receiver each need a copy of the OTP and must insure no one else has a copy. The OTP should be physically exchanged, not transmitted.
Each byte of the OTP is only used once – so there is no “statistical pattern” that an adversary could use to crack the message. (More info is at: http://en.wikipedia.org/wiki/One-time_pad.)
The unbreakability of one-time-pads rests on three factors:
1. Every byte in the OTP is generated by a truly random (unpredictable) process.
2. Every byte in the OTP is used only once.
3. The sender and recipient insure that no one else could have a copy of the pad.
When these are true, the OTP is unbreakable – there is no vulnerability that can be exploited.
How Product X works (I think)
Note: This is not a comprehensive evaluation of “Product X”, but rather my personal quick comparison of the information on their website to One-time-pads. Their website does not have a complete technical description, so I’ve made some assumptions that could be inaccurate.
If I understand correctly, “Product X” works like this:
- “Product X” uses a USB device and some software to provide secure authentication (login) from the user’s client system to a remote server.
- The user supplies a User ID and a Password on the client system.
- The User ID is sent to the server software, which selects an “index” that is sent back to the client.
- The “index” and secure information in the USB device create a “one-time password”, claimed to be equivalent to a One-time-pad.
- The “one-time password” is used to securely transmit the User’s password to the server.
Is “Product X” the equivalent of a one-time-pad?
Let’s look at the factors that make one-time-pads unbreakable:
1. Every byte in the OTP is unpredictable.
I will assume they got this right. You can use random.org, or several other techniques.
2. Every byte in the OTP is used only once.
I don’t think this is the case. I believe the “index” sent back from the server, works with the USB device to “randomly” select a pad. If enough logins happen, eventually pads will get re-used.
The Snake Oil website says:
OTPs are seriously vulnerable if you ever reuse a pad. For instance, the NSA’s VENONA project [4], without the benefit of computer assistance, managed to decrypt a series of KGB messages encrypted with faulty pads. It doesn’t take much work to crack a reused pad.
How soon are pads reused? The “Product X” website mentions “billions”, but doesn’t give specifics.
3. The sender and recipient insure that no one else could have a copy of the pad.
I don’t think this is the case. I believe all users share the same set of pads (otherwise the remote server would need a huge amount of per-user data).
However, I believe the role of the USB Device is to scrambles the pad selection on a per-user basis. I think security experts agree – a device like this (assuming well implemented) with a physically secure secret, provides significant security advantages.
So, the strength of “Product X” is based on:
- Could an adversary detect re-use of a pad?
- Could an adversary subvert the secret in the USB device?
This is the point of the “Snake Oil” FAQ. The strength of “Product X” is based on its own implementation details – not the “unbreakable” strength of one-time-pads.
I hope users of “Product X” also understand that it *ONLY* provides special security for the authentication step (the communication of the password). It does not help with the rest of the communication between the client and the server.
Since One-time-pads are so dang secure, why aren’t they used for everything?
OTPs have two important limitations:
- They must not be reused, and need to have as many bytes as the messages they are encoding. This is not practical if you’ve got gigabytes going back and forth every day.
- There must be some other secure mechanism to get the pad from one party to the other. That’s hard to do if you’re communicating with someone you’ve never met before (common on the web).
The Snake Oil FAQ lists many other things to watch out for, such as:
-
Secret Algorithms
-
Revolutionary Breakthroughs
-
Experienced Security Experts, Rave Reviews, and Other Useless Certificates
by Klaus Heinrich Kiwi, IBM LTC Security Team.
In the Information Security world, authentication and authorization are orthogonal concepts:
- Authentication refers to the act of correctly identifying an user or other entity, e.g.: making sure a user is who he really say he is. This is often done by associating passwords or keys to user accounts.
- Authorization refers to the act of granting access from certain users to certain services or resources, e.g.: allowing the user john_doe to read the file /foo/bar. This is usually done by mapping users and groups to resources through the use of permissions.
Kerberos is a network authentication protocol aimed at providing secure and reliable authentication semantics over an insecure (open) network. In a glimpse, it relies on symmetric key cryptography and in a trusted third-party to provide mutual authentication between two entities (called Principals in Kerberos nomenclature). This means that in a scenario where a user is authenticated against a network service, not only the service can be sure of the user identity, but the user can also be sure that he is communicating with the right server. All of this is done without exposing clear passwords or keys in the network.
The Kerberos Protocol is a standard (RFC 4120) with different implementations such as Microsoft’s Active Directory, Heimdal, the AFS kaserver and the Open Source MIT-Kerberos implementation.
LDAP, on the other hand, is an information retrieval protocol for accessing special purpose databases, called Directories. Directories are usually optimized for reading (queries) as opposed to writing operations (inserts), thus they are often used in write once, read many scenarios. This optimization aspect, associated with the hierarchical manner the objects are organized in the database makes LDAP an ideal choice for performing the mapping operations an authorization system needs.
LDAP is also a standard (RFC 4510, RFC 3494 among others) with numerous implementations such as the Open Source OpenLDAP and the IBM Tivoli Directory Server, aimed at enterprise use.
Since release 1.6 of the Open Source MIT-Kerberos (krb5) implementation, it is possible to combine the powerful authentication aspects of the Kerberos Protocol with the reliability and scalability provided by LDAP authorization. Such feature is included in recent enterprise distributions like Red Hat Enterprise Linux 5 series and Novell SUSE Linux Enterprise Server 11 and later, giving those platforms the possibility to benefit from combining the Open Source MIT-Kerberos implementation with the enterprise features of IBM Tivoli Directory Server.
It was with the intention of demonstrating how the above scenario can be achieved that I wrote a Blueprint covering the subject of Using MIT-Kerberos fo IBM Tivoli Directory Server backend.
Blueprints are documents describing the detailed plan of action for a specific task involving IBM hardware or technology. Blueprints bring a step-by-step description showing the exact actions needed to perform a certain task. Those steps are written with the expertise from the Software Engineers who actually work on development, but are also tested for correctness inside IBM labs – an IBM-branded HOWTO.
Besides the above Blueprint, please check-out the other publications I’ve authored or co-authored, including the Enterprise Multiplatform Auditing Redbook and my Logical Volume Management developerWorks article.
And as always, feedback is greatly appreciated!
Malware (malicious software), not virus, is the general term for software that is designed to behave badly. Malware encompasses the complete line of viruses (boot sector, stealth, polymorphic, multipart, self-garbling), worms, trojan horses, logic bombs, rootkits, etc. As you can see by the list above, malware comes in many shapes and sizes. We previously talked about viruses, so let’s briefly address some of the other forms of malware.
A trojan horse is malware that comes packaged along with something that the user does desire (data, software, whatever). Open source software has been attacked a few notorious times via trojan horse attacks. The most infamous is probably the time in 2002 that the OpenSSH server was compromised and versions of OpenSSH were replaced with trojaned versions of SSH. You can still read the CERT Advisory about the attack.
A worm is a piece of software that exploits a vulnerability to get itself established on a host and then uses that host to attack other systems. A worm is self-replicating and stand alone. The most notorious worm that affected many Linux systems was called L10n and attacked via bind in 2001.
A rootkit is a program designed to hide that malware in on the system. Rootkits have taken the form of kernel modules, binary replacements for key system utilities (ls, ps, etc.) which hide malware processes and files from the output that administrators uses to see what is happening on the system.
A botnet is a network of subverted machines that are running a rootkit or other malware on their system that makes them remotely directable. Botnets are frequently used to launch distributed denial of service attacks. The evolution of botnets is fascinating because they have gained sophistication in command and control structure to avoid single points of failure. In a very interesting turn of events, two Symantec researchers discovered the first Mac botnet. The botnet malware was distributed as a trojan horse connected to pirated iWork ’09 software.
This covers just a few of the additional types of malware and as you can see there are many. The study of malware is one of the “cooler” (or just more flashy) specialties of the computer security profession.
This article was part three in a multi-part series about anti-virus and Linux which was announced in the article Anti-virus for Linux Redux.
by George Wilson <gcwilson@us.ibm.com>, IBM Linux Technology Center
Operating system security features are notoriously difficult to explain. Folks who work on security have their own specialized vocabulary, which serves well to communicate concisely with other members of our community. However, it can be difficult to translate concepts into everyday language. Have you ever tried talking about SELinux to those who have never been exposed to MAC? You have to provide a large amount of background material simply to describe what SELinux is, let alone what interesting things can be done with it.
The LTC Security Development Team have developed a number of security features over the years. We’ve discussed them on mailing lists, written conference papers, and otherwise communicated our work to other technical folks. However, explaining the relevance of Linux security features to non-geeks remains a difficulty.
To help address the communications gap, the LTC Security Development Team in concert with the Information Development Team have created a customer-level Linux security brochure. In it, we discuss the various capabilities we have helped bring to Linux distros. Please take a look. It is available for download here: ftp://ftp.software.ibm.com/linux/pdfs/LTC/SecurityTeam.pdf, which BTW is one of the many resources available from the LTC Library here: http://www-03.ibm.com/linux/ltc/whitepapers.html.
In brief, some cool links:
Rational Survivability is a very readable blog focusing on the timely issue of cloud security. I especially liked yesterday’s entry: Private Clouds: Even A Blind Squirrel Finds A Nut Once In A While which discusses the differences between a private, public, managed and hybrid clouds calling out the level of trust you should place in each. I also enjoyed one from last month on How to be PCI compliance in a cloud…. What I like most about this blog is the clear and rational dissection of the technology and hype around cloud security expressed in a fairly sassy, funny, non-mean tone.
Wietse Venema’s RFC for PHP taint. Added a TODO to my list to try this out and see whether I can still get my blog to run.
A few noteworthy developerWorks articles:
Ramon de Carvalho Valle has a two part series on triggering buffer overflows on Power and Cell B.E:
LoP/Cell/B.E.: Buffer overflow vulnerabilities, Part 1: Understanding buffer overflow issues for Linux on Power-based systems
LoP/Cell/B.E.: Buffer overflow vulnerabilities, Part 2: Discovering how buffer overflow mechanisms work for Linux on Power-based systems
I’m hoping that he produces a third part to this series discussing overcoming buffer overflows on Power and Cell B.E.
Serge Hallyn has written yet another excellent security article on developerWorks, this time on Secure Linux containers cookbook. What I liked about this article is that he included the recipe for containing containers using Smack.
