Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I'm desperately trying to find the article I read a few weeks ago the outlined exactly the process of SMC emulation, what information the "keys" contain, how they're generated, and how they're used. SMC stands for System Management Controller. The primary function of the SMC is to manage power through the system and control fans. In the process of the SMC's primary function, data necessary for the operation of that function is generated and transmitted. It's that data, which has the primary function of managing power, that is co-opted by Apple as their top-secret redacted encryption scheme (i.e. the "key"). There just is no encryption or decryption going on.
we don’t know how accurate that is since Apple has not confirmed the accuracy of any information. It’s just a guess. And agin, the fact that there is a control measure there and it is sufficient (as ruled in court), thats all that’s required. Again, see my various cites. Encryption and decryption is not a necessary requirement. It’s just one method.

When I say of the key that it's easily accessible I don't mean that it's easily accessible over the internet. I mean that the data is completely unhidden ordinary run-o-the-mill system power management data. That's it's primary purpose; that's the reason the data exists. Apple's OS simply makes sure that data exists in order to allow an install. That data can exist with or without an actual SMC. The question is whether generating that data is a violation of DMCA.

From what I read, it just has to be effective for the casual user. A casual user would have no idea of such a system. Again, availability to the internet has been ruled as spurious. Read the example that Groklaw stated - the publishing of a book on the coke recipe doesn’t change the fact that it is a secret and the average consumer cannot tell.

Imagine the following scenario. Apple designs it's OS so that it only installs when the computer's microphone detects a certain sequence of hand clapping sounds. Apple employees know this hand clapping sequence and Apple's policy is that only Apple employees are authorized to install copies of the OS. When the Apple employees engage in the clapping procedure they don't take care to ensure that non-Apple employees can't hear or see it. Now, in this case, the clapping sequence's primary function is to control access. Additionally, in the ordinary course of the clapping sequences operation (being clapped by an Apple employee), the protection mechanism prevents access to a copyrighted work. If somebody observes the clapping, and since Apple doesn't take much if any care of hiding it many people do observe the clapping, is it the case that if those people clap the sequence and install the OS they violate the DMCA?

Based on my interpretation and reading - that would still qualify - as long as Apple rules it a trade secret and take reasonable measures to ensure that average consumers are aware of it or it’s purpose - it can be a DMCA claim.

The case of the SMC is worse than the clapping scenario since the SMC wasn't even designed as a preventative measure. It's primary function, per Apple's own documentation, is to manage power. The information it passes around the system isn't hidden or encrypted and apparently accessing the information is quite a simple procedure; akin to being in the room when somebody yells a "secret" password to their friend.
I don’t think your scenario is fair. Apple does not “disclose” this information. Somebody had to guess it and guess how to emulate it.

The footnote about key-ness is interesting. Essentially, just having a key is a sufficient condition to a mechanisms being a security measure. The question is whether the output of an unencrypted bit of information from circuitry that was not built for the purpose of providing security measures counts as a key. I mean, theoretically, an SMU from a PC could be designed such that it happens to output the same bits with respect to the hardware it manages that the SMC outputs for the hardware it manages, even though the hardware is different. If that were to happen, presumably OSX would install on that PC. Would that count as a DMCA violation?

I am not sure what your asking. How would the PC know what the SMC response would be. That would require knowing information that Apple views as a trade secret. That would warrant a DMCA notification since DMCA involves average consumer - not what a computer hardware vendor knows. And the DMCA is only one part of the copyright picture. It’s all hypothetical since if that method no longer works, they would use another one.

Look at this from a real life perspective. Suppose I am a burglar who is a skilled lock pick. Suppose I also like to make my work as easy as possible, and choose locks in which I have extensive knowledge about (suppose my hobby is locksmithing) which is far more than your average person or punk. I rob a building by picking the lock that I know is inferior to my skills and that the lock company surely do not make public. Regrettably I get caught. I cannot legitimately justify my actions by pointing out that the locks technical details are on the net (where I acquired them and picking them is readily available) and that the means to pick the lock are simple to bypass that anybody could do it. That just won’t fly. The intent of the lock is to keep me out. Apple adapted a prior system to accomplish the same thing. Section 17 doesn’t distinguish the method - it’s all about intent and how effective that is.

The standards concern the ability of the average user acting on their own. Hackintoshing to this point always has required assistance and instruction from a third party. The normal function of the disc is for it to work on Apples hardware. That is Apple’s intent defined in several sources.
 
Very interesting. Thanks for providing that.



I'm desperately trying to find the article I read a few weeks ago the outlined exactly the process of SMC emulation, what information the "keys" contain, how they're generated, and how they're used. SMC stands for System Management Controller. The primary function of the SMC is to manage power through the system and control fans. In the process of the SMC's primary function, data necessary for the operation of that function is generated and transmitted. It's that data, which has the primary function of managing power, that is co-opted by Apple as their top-secret redacted encryption scheme (i.e. the "key"). There just is no encryption or decryption going on.

When I say of the key that it's easily accessible I don't mean that it's easily accessible over the internet. I mean that the data is completely unhidden ordinary run-o-the-mill system power management data. That's it's primary purpose; that's the reason the data exists. Apple's OS simply makes sure that data exists in order to allow an install. That data can exist with or without an actual SMC. The question is whether generating that data is a violation of DMCA.



Imagine the following scenario. Apple designs it's OS so that it only installs when the computer's microphone detects a certain sequence of hand clapping sounds. Apple employees know this hand clapping sequence and Apple's policy is that only Apple employees are authorized to install copies of the OS. When the Apple employees engage in the clapping procedure they don't take care to ensure that non-Apple employees can't hear or see it. Now, in this case, the clapping sequence's primary function is to control access. Additionally, in the ordinary course of the clapping sequences operation (being clapped by an Apple employee), the protection mechanism prevents access to a copyrighted work. If somebody observes the clapping, and since Apple doesn't take much if any care of hiding it many people do observe the clapping, is it the case that if those people clap the sequence and install the OS they violate the DMCA?

The case of the SMC is worse than the clapping scenario since the SMC wasn't even designed as a preventative measure. It's primary function, per Apple's own documentation, is to manage power. The information it passes around the system isn't hidden or encrypted and apparently accessing the information is quite a simple procedure; akin to being in the room when somebody yells a "secret" password to their friend.

The footnote about key-ness is interesting. Essentially, just having a key is a sufficient condition to a mechanisms being a security measure. The question is whether the output of an unencrypted bit of information from circuitry that was not built for the purpose of providing security measures counts as a key. I mean, theoretically, an SMU from a PC could be designed such that it happens to output the same bits with respect to the hardware it manages that the SMC outputs for the hardware it manages, even though the hardware is different. If that were to happen, presumably OSX would install on that PC. Would that count as a DMCA violation?

Here is a description of the binary encryption that Apple uses and how if relates to the encryption key embedded in the SMC.

http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/
 
Here is a description of the binary encryption that Apple uses and how if relates to the encryption key embedded in the SMC.

http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/
I am sure Apple is not going to authenticate it of course. They are going to say (if anything) is "that's not accurate". If this site is to believed here is teh relevant point:

What is the correct answer?
The key (actually, a pair of 32-byte values) comes from the System Management Controller (SMC). Unlike in the case of a TPM, accessing this key involves no cryptography, no random numbers, no hardware security—it's merely obfuscation. Just as you can use I/O Kit interfaces to retrieve motion sensor data and numerous other readings from the SMC, you can retrieve the key—no number crunching involved. You don't even need superuser privileges. In fact, assuming you know how to access hardware from user-space, a program to do this would be quite straightforward to write on Mac OS X—perhaps around 50 lines of C.
Figure 1 shows such a program.
Why Obfuscate?

I view the obfuscation approach as engineering pragmaticism in solving difficult problems. The problem here was that of making Mac OS X reasonably difficult to deploy (from a legal standpoint—that is, would involve reverse engineering, breaking the EULA, etc.) on non-Apple hardware. A solution based on the TPM would have been fraught with numerous problems for the developers and maintainers of the solution. As is not uncommon in such cases, obfuscation can be an effective enough solution.

Emphasis mine...

My guess is that guy is saying that the obfuscation is enough - any attempt to load OSX on other hardware would require reverse engineering of some kind - which would prompt legal action (again , DMCA says that there just has to be a system there that affects the average user and does an effective job). Going through this effort is something that the average user probably cannot do with outside help which to me sounds effective.

I see that the same as lockpicking. Just becasue a burglar can figure out how to pick a padlock or the prevalence of picking information on the net, that doesn't negate the purpose of the lock and the wrongness of breaking it.
 
I am sure Apple is not going to authenticate it of course. They are going to say (if anything) is "that's not accurate". If this site is to believed here is teh relevant point:



Emphasis mine...

My guess is that guy is saying that the obfuscation is enough - any attempt to load OSX on other hardware would require reverse engineering of some kind - which would prompt legal action (again , DMCA says that there just has to be a system there that affects the average user and does an effective job). Going through this effort is something that the average user probably cannot do with outside help which to me sounds effective.

I see that the same as lockpicking. Just becasue a burglar can figure out how to pick a padlock or the prevalence of picking information on the net, that doesn't negate the purpose of the lock and the wrongness of breaking it.

Points taken. And thanks baldimac for finding that article.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.