while the fact that they're not randomizing the encryption is incredibly bad, it's not epic fail
A signer screwup that leaks their private key is not epic fail? This is probably the first time in embedded system security that someone has fucked up public key crypto this badly.
For epic fail, we go to the Xbox 360 which has a damn JTAG pinout exposed to the world on the fucking motherboard(runner up: Xbox pogo pins).
So does the PS3. JTAG doesn't mean anything if it's disabled, which it normally is, on both consoles (actually, we suspect it might be enabled on the PS3 but you probably can't do anything interesting with it). The Xbox 360 security design is a lot better than the PS3's. They had a few minor holes. The PS3 is completely messed up. The 360 has better revocation, better encryption, secure memory, a simpler and more effective security design, and a better implementation.
Also, why didn't you guys list sjeep's Independence Exploit for PS2 that came out in 2002 or so? It didn't directly enable piracy(although when HDloader got dumped into ELF format it sure did).
That came a lot later than modchips (which already enabled homebrew and piracy equally, since there's no PKI), and the slide was already overcrowded so it didn't make much sense.
Geohot developed his exploit because OtherOS wasn't offered for the PS3 Slim, and the PS3 Fat was discontinued. So yes, Sony started this by removing OtherOS on the Slim, and made it ten times worse by forcibly removing this on the Fat.
The "pitfall" isn't a pitfall because it doesn't apply to correctly implemented ECDSA. As long as you use a random m for every sig, you're safe. If you reuse m just once (or you somehow let the attacker guess m, or even an incomplete part of it), you leak the private key. If anything, the only con is that ECDSA requires a random number source for signing.
This is basically just a superficially subtle screwup that turns out to have massive consequences for the security of the cryptosystem.
Sony cannot permanently regain any existing PS3 with a firmware update (nor can they fix this hole trivially at all, including in new manufactured units). They can make it harder for you to install a hacked firmware on a PS3, but as of today every manufactured PS3 is vulnerable to a modchip (NOR/NAND flasher) forever.
Assuming they don't botch signing with the new key, no, we don't. The code running on the PS3 is perfectly fine (the signature verification, that is; the rest of the security is a clusterfuck). So is the way the signature is implemented. The screwup is in Sony's signer code. If they fix that and only issue safe signatures from now on, we can't compute new keys.
But because we can downgrade and due to the oracle attack on the secure SPE, this will likely not gain them much.
This is exactly the only possible fix. It is, however, technically quite hard to pull of for a number of reasons. I'm not at all certain that Sony will do that. They need to build a hash list of every version of every game, package, downloadable cotent, deal with shop versions and stuff like that, etc...
Although the keys are kind of short (they likely will become breakable in a few decades or something like that), that has nothing to do with the screwup. They completely botched their signer so it creates correlated signatures that leak the key. The computation to get the private key takes milliseconds.
The "epic" part really came about due to the completely inexcusable ECDSA signature screwup. We were left speechless by that one. However, as a whole, the entire PS3 architecture is terrible. Especially after breaking it open and properly analyzing it and finding a ton of screwups (many critical), there is absolutely no doubt in our mind that the sole reason why the PS3 lasted this far is because OtherOS kept all the competent people happy enough not to try to break into the system (that, and maybe hype around their hypervisor and isolated SPE security, both of which turned out to be terribly bad). If you watch the talk you'll actually see that we make this point clear and address the time-to-hack of the PS3. Given our experience and what we've learned from people who work on console hacks, almost nobody tried until OtherOS was removed, so the only valid measurement for "time to hack", as a strength-of-security measure, is the time since OtherOS was removed (9-12 months or so).
I'm one of those guys, and the summary is so terrible it's not even funny. Please watch the recording of the talk before you form an opinion; the reporting on this one is pretty terrible. Especially the "overflowing the bootup NOR flash". I don't even know what that's supposed to mean.
The PS3 security system really is horrible. Most of it is effectively useless because it can be worked around or breaking it is not necessary, and the signature screwup is basically inexcusable. We aren't calling it "Epic Fail" for one or two holes, we're calling it "Epic Fail" because as a whole it's a complete clusterfuck and there are many fundamental design holes and more than enough evidence that the developers responsible for it were not qualified to design a security system or write its code (e.g. clearly they didn't employ a proper cryptographer). It's also a reference to our Wii talk (which was subtitled "Wii Fail") because we consider the PS3's security to be a hell of a lot worse, design-wise.
There was basically no knowledge of the PS3 10 or so months ago. There was literally zilch besides a minor OtherOS 3D graphics hack until Sony released the PS3 Slim without Linux. No one cared, or at least no one who knew what they were doing cared, because they were happy with Linux. I've yet to meet someone who 1) was actively trying to hack the PS3 before they pulled OtherOS and 2) actually did something worth mentioning once this whole thing took off. The (few) people who were trying were (and still are) clueless, and the people who know started after the OtherOS mess. OtherOS was a great way to keep the hackers happy, and pulling it has been a great way to get everyone to target them.
Most of the "original" Spanish text on the demo video is Spanglish anyway. I bet if they were translating signs written in actual, correct Spanish, their automatic English translation would be even worse than it already is.
Total revenue right now is $861,710.88, let's say $850k. Linux users are just under a quarter of that, let's say 22%. So Linux users are responsible for $187k. The average Linux contribution is $13.61, so that's circa 13700 Linux buyers. Of note, the top contributor paid $2k, so no one Linux user is accountable for the vast majority of the $187k or anything like that. With sample size that large you can be pretty sure the numbers are meaningful.
The same calculations say they have about 75400 Windows buyers and about 22200 OSX buyers. So Linux makes up 12% of the userbase and 22% of the revenue (ish, guesstimating a bit by the graph), OSX makes up 20% of the userbase and 22% of the revenue, and Windows makes up 68% of the userbase and 56% of the revenue. Doesn't sound to me like any of the three OSes are worth ignoring at all. Not to mention the game developers are saying that Linux ports are more than paying for themselves.
Ah, but you see, the Kinects *know* what pattern to expect (they correlate with a known pattern) and ignore extraneous data, so in practice the interference between two or three kinects is minimal and only results in a few scattered small "holes" (that you fill in with data from the other device). I didn't think it would work at first, but, in fact, it does.
Nor can the camera in the article. They keep talking about "being able to see the scene from any point", but that's a load of bullshit. All they've done is combined a 360 camera array (what Street View does) with stereoscopic vision (what regular 2-camera 3D does) to get a 360 view with depth information. So now you can look around in a scene in 3D, but you can't change your position. The camera still sees the scene only from one viewpoint, it's just that it has a full hemispherical field of view plus depth/3D info. Cool? Yes, but hardly a breakthrough, and definitely nothing like what they claim it does.
If the camera can't see something because it is obscured by another object, then it can't see it, period. The camera has a bit more info due to the use of multiple lenses somewhat offset from each other, but that's just like regular stereoscopic vision, and your viewpoint is still severely limitedd. You can do a better job of 3D scene reconstruction with three or four Kinects in different places than with this, since then you can actually obtain several perspectives simultaneously and merge them into a more complete 3D model of the scene.
The DIY workaround to that would be to cut open a short VGA cable, break out the DDC pins, and solder in a tiny DDC EEPROM with a fairly bog standard configuration written to it. You could even fit the EEPROM inside a VGA connector if you wanted.
Re:That's one heck of a "long goodbye"
on
Goodbye, VGA
·
· Score: 1
Keyboards and mice are still in USB 1.1 land, controller-wise. I don't think we'll ever see USB 3.0 input peripherals at this rate.
Re:That's one heck of a "long goodbye"
on
Goodbye, VGA
·
· Score: 1
The culprit is this paragraph in the USB HID 1.11 spec:
The order of keycodes in array fields has no significance. Order determination is done by the host software comparing the contents of the previous report to the current report. If two or more keys are reported in one report, their order is indeterminate. Keyboards may buffer events that would have otherwise resulted in multiple event in a single report.
They could've just as easily specified that keys pressed are appended to the buffer in order, or at least that the buffer should be parsed in order (such that good keyboards could take advantage of this ability to reduce errors when two keys are pressed near simultaneously). But noooo. Dammit, USB is so ass-backwards it isn't even funny.
Plus a 16-byte IV, but that can just be all zeroes and isn't strictly speaking required (you do not need it to decrypt the file, except for the first 16 bytes).
No, Google optimizes its JavaScript in order to reduce size and execution time. That just happens to make it quite hard to read. Think "compiling" JavaScript into a smaller, not-meant-for-humans form.
This is different, it's deliberate obfuscation designed to make the script hard to read, while doing nothing for performance. It's a simple version of source or executable obfuscation. A more elaborate example would be the stuff that Apple does to their iTunes DB hashing algorithm to lock users into iTunes and stop people from interoperating with their devices from Linux (which also makes the code hilariously slow and bloated, but extremely hard to read).
No, because iPhone hacks can be used for copying copyrighted software (legally or not) and for running unauthorized software. Xbox 360 drive hacks can only be used for copying copyrighted software, legally or not. If you want to run unauthorized software you need an entirely different class of modification, which as far as I can tell is not what this guy was performing.
It's a freaking computer that's locked down.
And after patching the drive firmware, it's still locked down, and you still can't run your own applications or improve functionality in any way. All you can do is copy games. This is not comparable to iPhone jailbreaks in any way, shape, or form.
Your whole post is extremely misinformed. What can't you figure out? You can't come to grips with the fact that drive hacks can only be used and are exclusively performed for the purpose of copying games? This is a technical issue, not an argument or an opinion. It's not that people do this mostly to pirate games (which, in my opinion, they do); it's that that you can't physically do anything other than copy games. The only technical use for drive hacks is copying games.
You take an Xbox to this guy's shop. You get it back. There are only two functional changes to the xbox after coming out: it can run games burned to DVD-Rs, and it's likely to get banned on Xbox Live. Nothing more, unless we're missing information and he was also performing other classes of modifications. It won't let you run Linux on it.
FYI, I'm one of the people responsible for enabling and encouraging homebrew software on the Wii, so I think I know a little bit about secure systems with signed code. On the Wii, buying a modchip will gain you absolutely nothing with regards to running homebrew software. Or even imports. Period. The only reason why people buy Wii modchips is to copy games, because that is their only technical purpose.
The purpose and actions are most certainly not the same. As I understand it, modding Xbox 360 drives doesn't even enable you to run homebrew (except through obsolete hacks that no longer work on recent Xboxes). Same with modding Wii drives. They don't even let you use imported games. The only two purposes for drive-hacks on secure consoles (which sign code and region restrictions) are piracy and backups, and you can take a guess as to what the actual, practical percentage of people doing either of those is. The age of modchip = copies = homebrew was last generation. This generation people who want to pirate games just compromise drive security, which is useless for homebrew because the code is signed.
It's easy to compare all "mods" to iPhone hacks, but the majority of jailbreak users do so either to run unofficial software or to unlock their phones, while the vast majority of console modders (especially hardware modders) do so exclusively to pirate games.
Now, if this were about PS3 hacks (which are software-based), or Wii homebrew (software-based) hacks, both of which can be used for homebrew or piracy, then you'd have a point. But it isn't, it's about drive hacks attacking the weak point in media security, doing nothing for homebrew.
Two main reasons: Embedded device peripherals, and USB device development. Sometimes you don't have access to the OS running on the host to set up a sniffer (game consoles, some smartphones, and similar). And sometimes you need to debug a USB device that you're developing, and software USB sniffers don't provide the kind of detail needed to do that effectively (some errors are only evident when you watch the stuff on the wire, not the high-level requests).
Also, software sniffers are imperfect. I've had issues with them. A physical hardware device is completely transparent and can work without either side noticing anything. Sure, you can make do with a software sniffer sometimes, but that doesn't mean there's no point to a hardware version.
And since this is open, it can be repurposed for other uses. For example, you could use only the device port, and turn it into a kind of usb device-to-device bridge that lets your computer impersonate a USB device. That is currently not possible except on embedded systems with USB device controllers, and those have limitations. You could also use it as a pretty good logic analyzer, given proper firmware.
There is some processing going on in the Kinect, but only to measure the spacing (and perhaps size) of the IR dots that are being projected by the device in order to produce a depth-map. This processing is clearly mostly trivial.
No it isn't, and that's not how the algorithm works. As the camera is placed very near to the IR projector, the dot spacing is essentially constant. The dots may be farther apart in physical space for farther objects, but the camera can't see that.
As far as we can tell/guess, the way it actually works is by measuring horizontal displacement of the dots caused by objects at different depths, due to the horizontal distance between the projector and the camera. This is a lot harder, requires subpixel processing to achieve any kind of depth resolution, and requires a carefully controlled dot projection and calibration to that specific pattern. Not to mention this is likely the reason why the laser projector is temperature-stabilized with a peltier (to keep the pattern as generated by the diffraction grating stable) and why the Kinect's internal chassis is quite solid (the distance between the camera and projector and their angle is critical).
In fact, you can point two Kinects at the same subject and overlap their IR patterns, and they still work quite well and do not interfere (!) except at a small percentage of points where the clouds line up in the wrong way (you get two almost complete images, with a bunch of small holes where the patterns happen to line up).
Slashdot Mirror
A signer screwup that leaks their private key is not epic fail? This is probably the first time in embedded system security that someone has fucked up public key crypto this badly.
So does the PS3. JTAG doesn't mean anything if it's disabled, which it normally is, on both consoles (actually, we suspect it might be enabled on the PS3 but you probably can't do anything interesting with it). The Xbox 360 security design is a lot better than the PS3's. They had a few minor holes. The PS3 is completely messed up. The 360 has better revocation, better encryption, secure memory, a simpler and more effective security design, and a better implementation.
That came a lot later than modchips (which already enabled homebrew and piracy equally, since there's no PKI), and the slide was already overcrowded so it didn't make much sense.
Geohot developed his exploit because OtherOS wasn't offered for the PS3 Slim, and the PS3 Fat was discontinued. So yes, Sony started this by removing OtherOS on the Slim, and made it ten times worse by forcibly removing this on the Fat.
The "pitfall" isn't a pitfall because it doesn't apply to correctly implemented ECDSA. As long as you use a random m for every sig, you're safe. If you reuse m just once (or you somehow let the attacker guess m, or even an incomplete part of it), you leak the private key. If anything, the only con is that ECDSA requires a random number source for signing.
This is basically just a superficially subtle screwup that turns out to have massive consequences for the security of the cryptosystem.
Sony cannot permanently regain any existing PS3 with a firmware update (nor can they fix this hole trivially at all, including in new manufactured units). They can make it harder for you to install a hacked firmware on a PS3, but as of today every manufactured PS3 is vulnerable to a modchip (NOR/NAND flasher) forever.
Assuming they don't botch signing with the new key, no, we don't. The code running on the PS3 is perfectly fine (the signature verification, that is; the rest of the security is a clusterfuck). So is the way the signature is implemented. The screwup is in Sony's signer code. If they fix that and only issue safe signatures from now on, we can't compute new keys.
But because we can downgrade and due to the oracle attack on the secure SPE, this will likely not gain them much.
This is exactly the only possible fix. It is, however, technically quite hard to pull of for a number of reasons. I'm not at all certain that Sony will do that. They need to build a hash list of every version of every game, package, downloadable cotent, deal with shop versions and stuff like that, etc...
Although the keys are kind of short (they likely will become breakable in a few decades or something like that), that has nothing to do with the screwup. They completely botched their signer so it creates correlated signatures that leak the key. The computation to get the private key takes milliseconds.
The "epic" part really came about due to the completely inexcusable ECDSA signature screwup. We were left speechless by that one. However, as a whole, the entire PS3 architecture is terrible. Especially after breaking it open and properly analyzing it and finding a ton of screwups (many critical), there is absolutely no doubt in our mind that the sole reason why the PS3 lasted this far is because OtherOS kept all the competent people happy enough not to try to break into the system (that, and maybe hype around their hypervisor and isolated SPE security, both of which turned out to be terribly bad). If you watch the talk you'll actually see that we make this point clear and address the time-to-hack of the PS3. Given our experience and what we've learned from people who work on console hacks, almost nobody tried until OtherOS was removed, so the only valid measurement for "time to hack", as a strength-of-security measure, is the time since OtherOS was removed (9-12 months or so).
OtherOS was Sony's single best security feature.
I'm one of those guys, and the summary is so terrible it's not even funny. Please watch the recording of the talk before you form an opinion; the reporting on this one is pretty terrible. Especially the "overflowing the bootup NOR flash". I don't even know what that's supposed to mean.
The PS3 security system really is horrible. Most of it is effectively useless because it can be worked around or breaking it is not necessary, and the signature screwup is basically inexcusable. We aren't calling it "Epic Fail" for one or two holes, we're calling it "Epic Fail" because as a whole it's a complete clusterfuck and there are many fundamental design holes and more than enough evidence that the developers responsible for it were not qualified to design a security system or write its code (e.g. clearly they didn't employ a proper cryptographer). It's also a reference to our Wii talk (which was subtitled "Wii Fail") because we consider the PS3's security to be a hell of a lot worse, design-wise.
There was basically no knowledge of the PS3 10 or so months ago. There was literally zilch besides a minor OtherOS 3D graphics hack until Sony released the PS3 Slim without Linux. No one cared, or at least no one who knew what they were doing cared, because they were happy with Linux. I've yet to meet someone who 1) was actively trying to hack the PS3 before they pulled OtherOS and 2) actually did something worth mentioning once this whole thing took off. The (few) people who were trying were (and still are) clueless, and the people who know started after the OtherOS mess. OtherOS was a great way to keep the hackers happy, and pulling it has been a great way to get everyone to target them.
I believe that's a mistranslation or a mistake by a Spanish speaker. In Spanish, "redactar" means "to write" (as in a book, an essay, a law, ...).
Most of the "original" Spanish text on the demo video is Spanglish anyway. I bet if they were translating signs written in actual, correct Spanish, their automatic English translation would be even worse than it already is.
Total revenue right now is $861,710.88, let's say $850k. Linux users are just under a quarter of that, let's say 22%. So Linux users are responsible for $187k. The average Linux contribution is $13.61, so that's circa 13700 Linux buyers. Of note, the top contributor paid $2k, so no one Linux user is accountable for the vast majority of the $187k or anything like that. With sample size that large you can be pretty sure the numbers are meaningful.
The same calculations say they have about 75400 Windows buyers and about 22200 OSX buyers. So Linux makes up 12% of the userbase and 22% of the revenue (ish, guesstimating a bit by the graph), OSX makes up 20% of the userbase and 22% of the revenue, and Windows makes up 68% of the userbase and 56% of the revenue. Doesn't sound to me like any of the three OSes are worth ignoring at all. Not to mention the game developers are saying that Linux ports are more than paying for themselves.
Ah, but you see, the Kinects *know* what pattern to expect (they correlate with a known pattern) and ignore extraneous data, so in practice the interference between two or three kinects is minimal and only results in a few scattered small "holes" (that you fill in with data from the other device). I didn't think it would work at first, but, in fact, it does.
Seriously, Slashdot can't handle the degree sign either? That's ISO-8859-1 for fuck's sake, not even one of the weirder Unicode characters.
Nor can the camera in the article. They keep talking about "being able to see the scene from any point", but that's a load of bullshit. All they've done is combined a 360 camera array (what Street View does) with stereoscopic vision (what regular 2-camera 3D does) to get a 360 view with depth information. So now you can look around in a scene in 3D, but you can't change your position. The camera still sees the scene only from one viewpoint, it's just that it has a full hemispherical field of view plus depth/3D info. Cool? Yes, but hardly a breakthrough, and definitely nothing like what they claim it does.
If the camera can't see something because it is obscured by another object, then it can't see it, period. The camera has a bit more info due to the use of multiple lenses somewhat offset from each other, but that's just like regular stereoscopic vision, and your viewpoint is still severely limitedd. You can do a better job of 3D scene reconstruction with three or four Kinects in different places than with this, since then you can actually obtain several perspectives simultaneously and merge them into a more complete 3D model of the scene.
The DIY workaround to that would be to cut open a short VGA cable, break out the DDC pins, and solder in a tiny DDC EEPROM with a fairly bog standard configuration written to it. You could even fit the EEPROM inside a VGA connector if you wanted.
Keyboards and mice are still in USB 1.1 land, controller-wise. I don't think we'll ever see USB 3.0 input peripherals at this rate.
The culprit is this paragraph in the USB HID 1.11 spec:
They could've just as easily specified that keys pressed are appended to the buffer in order, or at least that the buffer should be parsed in order (such that good keyboards could take advantage of this ability to reduce errors when two keys are pressed near simultaneously). But noooo. Dammit, USB is so ass-backwards it isn't even funny.
AES256 keys are 32 bytes.
Plus a 16-byte IV, but that can just be all zeroes and isn't strictly speaking required (you do not need it to decrypt the file, except for the first 16 bytes).
No, Google optimizes its JavaScript in order to reduce size and execution time. That just happens to make it quite hard to read. Think "compiling" JavaScript into a smaller, not-meant-for-humans form.
This is different, it's deliberate obfuscation designed to make the script hard to read, while doing nothing for performance. It's a simple version of source or executable obfuscation. A more elaborate example would be the stuff that Apple does to their iTunes DB hashing algorithm to lock users into iTunes and stop people from interoperating with their devices from Linux (which also makes the code hilariously slow and bloated, but extremely hard to read).
No, because iPhone hacks can be used for copying copyrighted software (legally or not) and for running unauthorized software. Xbox 360 drive hacks can only be used for copying copyrighted software, legally or not. If you want to run unauthorized software you need an entirely different class of modification, which as far as I can tell is not what this guy was performing.
And after patching the drive firmware, it's still locked down, and you still can't run your own applications or improve functionality in any way. All you can do is copy games. This is not comparable to iPhone jailbreaks in any way, shape, or form.
Your whole post is extremely misinformed. What can't you figure out? You can't come to grips with the fact that drive hacks can only be used and are exclusively performed for the purpose of copying games? This is a technical issue, not an argument or an opinion. It's not that people do this mostly to pirate games (which, in my opinion, they do); it's that that you can't physically do anything other than copy games. The only technical use for drive hacks is copying games.
You take an Xbox to this guy's shop. You get it back. There are only two functional changes to the xbox after coming out: it can run games burned to DVD-Rs, and it's likely to get banned on Xbox Live. Nothing more, unless we're missing information and he was also performing other classes of modifications. It won't let you run Linux on it.
FYI, I'm one of the people responsible for enabling and encouraging homebrew software on the Wii, so I think I know a little bit about secure systems with signed code. On the Wii, buying a modchip will gain you absolutely nothing with regards to running homebrew software. Or even imports. Period. The only reason why people buy Wii modchips is to copy games, because that is their only technical purpose.
The purpose and actions are most certainly not the same. As I understand it, modding Xbox 360 drives doesn't even enable you to run homebrew (except through obsolete hacks that no longer work on recent Xboxes). Same with modding Wii drives. They don't even let you use imported games. The only two purposes for drive-hacks on secure consoles (which sign code and region restrictions) are piracy and backups, and you can take a guess as to what the actual, practical percentage of people doing either of those is. The age of modchip = copies = homebrew was last generation. This generation people who want to pirate games just compromise drive security, which is useless for homebrew because the code is signed.
It's easy to compare all "mods" to iPhone hacks, but the majority of jailbreak users do so either to run unofficial software or to unlock their phones, while the vast majority of console modders (especially hardware modders) do so exclusively to pirate games.
Now, if this were about PS3 hacks (which are software-based), or Wii homebrew (software-based) hacks, both of which can be used for homebrew or piracy, then you'd have a point. But it isn't, it's about drive hacks attacking the weak point in media security, doing nothing for homebrew.
Two main reasons: Embedded device peripherals, and USB device development. Sometimes you don't have access to the OS running on the host to set up a sniffer (game consoles, some smartphones, and similar). And sometimes you need to debug a USB device that you're developing, and software USB sniffers don't provide the kind of detail needed to do that effectively (some errors are only evident when you watch the stuff on the wire, not the high-level requests).
Also, software sniffers are imperfect. I've had issues with them. A physical hardware device is completely transparent and can work without either side noticing anything. Sure, you can make do with a software sniffer sometimes, but that doesn't mean there's no point to a hardware version.
And since this is open, it can be repurposed for other uses. For example, you could use only the device port, and turn it into a kind of usb device-to-device bridge that lets your computer impersonate a USB device. That is currently not possible except on embedded systems with USB device controllers, and those have limitations. You could also use it as a pretty good logic analyzer, given proper firmware.
No it isn't, and that's not how the algorithm works. As the camera is placed very near to the IR projector, the dot spacing is essentially constant. The dots may be farther apart in physical space for farther objects, but the camera can't see that.
As far as we can tell/guess, the way it actually works is by measuring horizontal displacement of the dots caused by objects at different depths, due to the horizontal distance between the projector and the camera. This is a lot harder, requires subpixel processing to achieve any kind of depth resolution, and requires a carefully controlled dot projection and calibration to that specific pattern. Not to mention this is likely the reason why the laser projector is temperature-stabilized with a peltier (to keep the pattern as generated by the diffraction grating stable) and why the Kinect's internal chassis is quite solid (the distance between the camera and projector and their angle is critical).
In fact, you can point two Kinects at the same subject and overlap their IR patterns, and they still work quite well and do not interfere (!) except at a small percentage of points where the clouds line up in the wrong way (you get two almost complete images, with a bunch of small holes where the patterns happen to line up).