Slashdot Mirror
Apple Data Security Framework
rschroeder writes: "Apple has opened their Common Data Security Architecture framework, which "contains an expandable set of cryptographic algorithms to perform code signing and encryption operations while maintaining the security of the cryptographic keys." Lots of good info in addition to the code."
CDSA is more than just an equivalent of openSSL...
CDSA is a standard that was established by the open groups, a number of corporations are working on CDSA products, it does provide a large range of services other than providing a common API for cryptographic services, trust policy, certificate library and so on.
While it offers a standard way of securely communicating data, it also offers a common way to establish policies and the many things. it was meant to be a complete solution for security, especially for e-commerce.
It's nice to see an implementation openly available, if no one uses it it will still be easier to ensure interoperability with MacOS X...
Also it brings some publicity to CDSA, which is not bad.
In my opinion, it's a good thing.
The reality is, the Apple is not secure concerns are media spins by folks who are looking for a problem to write about. Not finding it, they write about "concerns" and play on the ignorant OS advocates and trollers, who respond and draw everyone else into the mix.
It's been like this for ages. Look at the /. articles. There's one that Apple is not being security conscious. Then there's an Ask Slashdot which accuses Apple of too many upgrades. Now this, where Apple has simply adapted technology to fit their machines--it's doubly played as if Apple invented it (they make no such claim) and is trying to take credit for it, and that Apple is upping security, as if Apple wasn't secure in the first place.
Sorry, but there have been MORE exploits for Linux than MacOS X from the time MacOS X has been released. Worse, Linux has been around awhile, while MacOS X, being the new, unproven OS, should have been littered with holes. The opposite proves true, but you won't have people in the media or other OS advocates pointing that out.
Ummm... who cares about Apple? CDSA was developed by Intel. Intel is responsible for the bulk of CDSA. Intel built the code with portability in mind. That's why Apple was able to port it. http://developer.intel.com/ial/security/ http://developer.intel.com/ial/security/press.htm Intel released the source code in 2000: http://developer.intel.com/pressroom/archive/relea ses/in092500.htm
For the last few versions, the Mac OS has been loading it's "ROMs" off disk early in the boot process. Look in the system folder for a file named Mac OS ROM.
Of course, you're probably still right but about some other bit of hardware. Macs still have NVRAM, after all.
Short answer: No.
Longer answer: It's a security framework with hooks to a lot of things. If you'd read at least the introduction you'd have seen that it does, indeed, contain support for SSL, PGP and many other standard security/encryption/ham-and-cheese-sandwich technologies. Actually it's the MacOS X implementation of the OpenGroup standard. I do not know (did not find information more like it), however, if they _did_ implement the whole schmiel.
Longer longer answer: read the OpenGroup documentation. Download the code. Read the code. Come back and tell us about it.
--Moo
A cool thing about the CDSA is that you can replace any part you don't like. So, if you feel the NSA has compromised it, you can replace the crypto portions with your own provider based on OpenSSL.
-Dave
Citizens Against Plate Tectonics
Secondly I don't see any references as to the encryption used - it's a MS-specific blackbox as far as I can tell. Considering MS's shaky history of security implementations & the general problem of closed-source encryption this isn't particularly comperable to Apple's Open Source implementation of an outside published standard written by broad coalition of interested users.
Finally what uses this? Win2k has literally thousands of API's, some excellent, some half-baked, some simply broken or braindead, many overlapping or redundant. Having an API is one thing, using it or getting it used is another, particularly in the archeology that is Win2k.
Under MacOS 9 & 10 the Keychain is availiable from within the Finder, the Chooser, it's more modern implementation the Network Browser, the en/de-cryption applets, MS's Internet Explorer, most FTP clients including Interarchie & Fetch plus numerous other applications.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
One of the features of MacOS 9 has been the ability to encrypt any file via a set of system-level services. A second feature has been the ability to use a "Keychain" service where passwords & other information can be securely stored & automatically retrieved by authorized applications. A third feature has been the ability to use a Voiceprint as a password.
Here are a number of examples of how these features can be used:
- Macs running MacOS 9 and greater support Multiple Users. Thus folks can (or must) log in in order to access their materials. This login can be accomplished via typed password or Voiceprint. Macs with access to an appropriate server can store individual preferences on the server and these can used applied from client Macs as the user logs in.
- In order to encrypt or decrypt a file under MacOS 9 and greater on need simply drag-and-drop the file/folder/drive to the encryption application. This service can also be called from within any application utilizing the cryptographic API's.
- Utilizing the "Keychain" any program can store or retrieve settings, passwords and other secured bits of information. Thus instead of saving one's web-account passwords in an easily read text file they're stored encrypted in a file where explicit authorization must be given for access. The same for the other various servers one might utilize regularly or occasionally - their login information and passwords can be stored under a single master-password and applied at need.
Now, lots of folks are going to start reading this and trying to imagine lots of ways they could break this, the possible downsides, etc. Yes, it's not completely foolproof. On the other hand it's a lot better then many other OS's offer, particularly when you realize it's widely supported throughout the OS and by many (most?) applications. Furthermore it seems fairly well thought out and after being out in the field a bit it seems to be working well.It's good to see Apple is finally documenting the same hooks in MacOS X. Presumably by completely opening the material a better evaluation of the processes can be made and improvements implemented by third parties. Furthermore since it's a standard promulgated by a number of companies all in the security field this has a good chance of being implemented in a wide range of products.
It would also be great if other OS development folks could take this code and use it to compare/contrast their own efforts in this direction and use them to improve themselves, possibly even work towards adopting some common material where the specs are vague.
Finally, before going and making wild-assed assumptions based on how you assume this stuff is implemented or blue-skying on it's possible flaws howzabout investing the 10 minutes and actually getting the facts first, not wasting all of the rest of ours time? This is all Open Source and it's well documented so it's not up to everyone else to teach you: Go read it for yourself.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
That said there's a long distance between Darwin & MacOS X. Carbon, Quartz, Aqua, QuickTime, Classic - all are critical parts of MacOS X that aren't in Darwin. Without them Darwin is an interesting BSD variant with a Mach-based kernel, reworked IO & some nifty OO & "Frameworks" support and innovative configuration-files-settable-via-XML technology.
That doesn't a clone make. Indeed it's debatable if Apple could themselves easily make a clone-able Mac at this point. So much of MacOS X (not Darwin) is PPC-specific and relies so heavily on Apple hardware implementations it might not be easily possible.
Sure Next was ported many times & MacOS X has inherited much of that flexibility but since then there's been massive rewrites. It's likely that most of everything above Darwin might require a lot of work now move to another architecture or even motherboard design, there appear to be lots of assumptions made in the design.
Sure there are always rumors of MacOS X running on x86/Alpha/etc. chips and there was a Rhapsody release that was cross-platform as well as stories of a beta MacOS 8 runnable on an IBM RS6000 but at this point it seems unlikely that the MacOS X now out there could be easily moved to either an Intel-standard motherboard architecture (BIOS/ Northbridge/Southbridge etc.) or to another workstation architecture using OpenFirmware etc.
Possible: Yes.
Easily Achieved: No
Possible by someone other then Apple? No
Darwin does not MacOS X make.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Yes, but there's still a boot ROM on the Macs. The ROM-in-RAM does load a "ROM" from a file on disk, but the Boot ROM (basically a BIOS) does quite a bit at startup. Here's info from the original iMac's developer notes:
"The Boot ROM contains the code needed to start up the computer, initialize and examine the hardware, provide a device tree to describe the hardware, provide hardware access services (RTAS), and control to the OS. The Boot ROM can be grouped into the following major pieces. "
Granted, this doesn't contain a significant portion of the OS, like the ROMs used to, but it's pretty key.
-jon
Remember Amalek.
-jon
Remember Amalek.
Uh, it is. By default, Mac OS X ships with Mac file sharing off, FTP off, Apache off, and ssh off. Telnet is disabled in all versions since 10.0.1. If you want to turn them on, it's just a checkbox, but 99% of all Mac users won't turn on any of them except for Mac file sharing, which should be pretty safe; I don't know of any AppleTalk exploits.
-jon
Remember Amalek.
No, it doesn't. Darwin alone isn't much more than a BSD variant, and I'd be pretty surprised if Apple isn't using the copyrighted ROMs on every Mac's motherboard as some sort of dongle for the higher-level Mac OS X functionality. You couldn't copy those ROMs without Apple's permission and that will happen over Steve's cold, dead body.
Whether or not Apple could survive under a licensing system is a different debate. But I doubt that it'd be possible technically without Apple's blessing.
-jon
Remember Amalek.
Xinet (available for Solaris/SPARC and Irix) does use encrypted AFP passwords, and otherwise does an excellent job as a Unix AFP server. Helios, on the other hand, uses cleartext passwords. Xinet costs a bit of money, but might well be worth it.
"2.You are permitted to read the HTML and PDF versions of Open Group publications using your HTML browser/Acrobat software and to download them for your own personal use provided you have given your name and email address for each publication requested. However, you are NOT permitted to amend, copy, reprint, offer for sale, or otherwise re-use material from these documents without explicit permission from The Open Group.
I assume "otherwise re-use material" would include actually implementing the specification.
Funny thing. I clicked to download the code, server authentication box came up. I entered nothing and clicked ok. Let me right through :)
I wonder if they are implementing their own procedures and standards.
rb
Is the the MacOSX equivalent of OpenSSL?
No. This is an extensible architecture that allows you to add modules for a ton of algorithms. Think of it more as a pluggable architecture something like Java's JCE.
I'd assumed that OpenSSL would work on MacOSX, given all the spiel about it being Unix based.
Mac OS X ships with TCPWrappers, OpenSSL and OpenSSH installed by default since version 10.0.1. There's a GUI interface available in the System Preferences panel to turn it on and off (if you're an administrator - ie. are in the wheel group).
For those of you wondering what a CDSA might really be, you can read all about it here at the opengroup.
Good stuff.
--
--
--
Keep in mind, that with the number of machines Apple sells, they're on track to be the volume leader for UNIX installations by the end of this year.
Fortunately, Mac OS X is pretty tight right out of the box. As installed, all services are *off*, and there is already a nice GUI app for configuring IPFW (BrickHouse.app, look for it on softrak at www.stepwise.com)
AFAIK, nobody running a NeXT machine ever got 0wn3d, despite a grievous early mistake in the window server, due to the platform being a very small target (~50K seats, max.)
Basically, any exploits that work on netBSD are a hazard for Mac OS X, except that they'll have to be re-compiled for PPC.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Hardly. Microsoft is a minority shareholder, and hardly has much weight to throw around in that manner.
The main leverage Microsoft has on Apple is the threat of cancelling MS Office for the Mac. But that does make MS a ton of money, so they're not just doing it for leverage purposes.
-- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
This seems like a good first step for Apple to be taken more seriously, especially given public concerns about Apple not taking security seriously.
I'm glad to have the opportunity to look into this framework now. Hopefully Apple will keep addressing the security holes that'll pop up elsewhere in the OS from time to time.
Will this silence the rabid anti-Apple critics who haven't used a Mac since 1984 (if ever)? Not a chance.
-- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
Any code posted on their Publicsource site is open for all comers. For example, OpenPlay runs on Mac, Win, and various *nixes.
As for CDSA, a couple other people are already working on Windows and Linux implementations.
Mac users won't turn on any of them except for Mac file sharing, which should be pretty safe; I don't know of any AppleTalk exploits.
Just because there are no exploits, doesn't mean you have security. (See my last sentence below.)
I remember from an Apple developer's conference about 1987 (yes that's EIGHY seven) that when the password traverses an AppleTalk network, it is DES encrypted, or something like that.
In recent years, you can use AFP (Apple Filing Protocol) over TCP as well as over AppleTalk. Now I don't know about Apple's implementation of AFP over TCP, but when I use a Netatalk server on a Linux box, the password is in the clear. Apparently, Netatalk doesn't have or use a UAM on the Mac side to scramble the password. Even bad ol' Microsoft does this -- although you need to use a custom UAM from MS to access AFP on an NT Server from a Mac. But it's easy, just drop the UAM into your System Folder. And has been this way for years. (UAM = <something> authentication module, or somesuch.)
At home, on Cable Modem, I have a Linux box, static IP, domain name. At work, using my Mac I sometimes mount my home directory using AFP. It's so easy. Just go to the chooser, mount it, etc. My home directory from Linux at home on my Mac desktop at work!
I've often suspected that the password goes naked (in the clear). I just now positively confirmed it. I ran Ethereal (from a Win98se box), while I mounted my home directory from home (Linux) to my Mac desktop. Yup, the password is in the clear. It's right there in the packets.
The next logical step is to write the cute dude responsible for dsniff to see what the possibilities are to get dsniff to reveal AFP passwords over TCP.
The irony of this is that Mac mounting an AFP server volume is insecure only when the server is a Linux box. (well, actually Netatalk)
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
The ROM in ROM is also known as Open Firmware; it's covered by an IEEE standard (off the top of my head, 1275?) and is also used by Sun (and I think a few other Unix-hardware makers) for their hardware. Not exactly proprietary...
Apple's got themselves in an interesting situation here. The more low-level stuff they put out for all to play with, the harder they lock down the high-level stuff.
Seems to me that Apple's in kind of a strange situation -- Darwin makes Mac cloning possible, at least for small operators. Apple needs to do some fast thinking at this point -- going completely Open Source is a good idea because MS-style licensing enforcement at this point goes out the window. But that means they need to start moving boxes, and more importantly, motherboards.
No doubt this is an interesting place for Apple to be working. They are giving up control, hopefully looking ahead to a point where software licensing is meaningless. That's good. Giving away an extensible crypto architecture is even better (not to mention that it makes hash of what little is left of export controls on crypto).
Apple should stay the course. Their next trick, though, needs to be establishing a commodity PowerPC hardware market. I'd be interested to see how that can be pulled off...
/Brian
Oh yeah! Well we can perform code signing AND encryption operations while maintaining the security of the cryptographic keys AND chew gum AND standing on our heads, walking backwards. Did we mention that it will cost a lot more?
Blarf.
Unless Apple releases it's code for Microsoft systems (it might, given it's streaming server and Quicktime softwares).
Apple code for Apple OS, right?
Geek dating!
GPL Deconstructed
Here's hoping someone at Apple fixes this before someone else not at Apple finds a way to hack the soon-to-be-masses of Mac OS X boxen en masse.