PRS-500 Analysis of USB trace for flashing Reader - Page 3

TadW · 02-15-2007, 09:01 AM

Quote:

Originally Posted by scotty1024

Your unit would then reject updates from Sony.

Not if you resign the images and put the signatures in the checksum file.

Quote:

The only clean fix for the USB Updater is to out a SHA-1 private key.

There ain't no private SHA-1 key. SHA-1 is a hash function, not an asymmetric key algorithm.

Alexander Turcic · 02-15-2007, 09:24 AM

I've been following this discussion with interest, and what surprises me is that Sony is trying to lock down access to the device. It's just so counterproductive.

It also reminds me of what iLiad hobby programmers went through - until iRex agreed, and supplied the necessary steps to access the iLiad.

igorsk · 02-15-2007, 09:29 AM

Well, I sort of can understand them... they're probably trying to prevent using unauthorized access to circumvent DRM. Except doing that on the device is not really practical - the desktop reading software is much easier to break into.

Alexander Turcic · 02-15-2007, 10:14 AM

Quote:

Originally Posted by igorsk

Except doing that on the device is not really practical - the desktop reading software is much easier to break into.

This is why I thought it was senseless. Except that it will cause a lot more hackers eaglery trying to circumvent the restriction, and what's the point of this.

scotty1024 · 02-15-2007, 11:22 AM

Quote:

Originally Posted by TadW

Not if you resign the images and put the signatures in the checksum file.

There ain't no private SHA-1 key. SHA-1 is a hash function, not an asymmetric key algorithm.

MD5 is a hash, SHA-1 is a cryptographic digital signature that uses a RSA key pair to securely sign a digital document. If Sony had simply wished to protect against file corruption they would have used MD5. The only reason to use SHA-1 is to control the sourcing of the open source firmware.

scotty1024 · 02-15-2007, 11:23 AM

Quote:

Originally Posted by Alexander Turcic

This is why I thought it was senseless. Except that it will cause a lot more hackers eaglery trying to circumvent the restriction, and what's the point of this.

What I find senseless is Sony spending man power implementing SHA-1 when they could have spent that man power on fixing the moth eaten PDF viewer!

FourOhFour · 02-15-2007, 12:05 PM

Quote:

Originally Posted by doctorow

Sorry my ignorance, but isn't this is a blunt violation of GPL? GPL dictates that you must provide the user a method to recompile the sources and reflash the unit. Sony is actively trying to prevent us from doing this. This is worse than just not delivering the necessary tools.

No, the GPL has no such requirement. The GPL requires that in order to distribute the binary, you must make available the source to the people you distribute the binary for no more than a reasonable fee for media. The GPL currently has no requirement that any hardware supports or permits modified binaries.

Version 3 of the GPL might have such a requirement, however Linux is licensed under version 2, so any such change won't help until and unless Linux moves to version 3 (unlikely) AND Sony updates to a Linux version after such a change (even more unlikely, if they want to keep people out of the hardware).

http://www.gnu.org/copyleft/gpl.html

porkupan · 02-15-2007, 01:35 PM

Quote:

Originally Posted by scotty1024

What I find senseless is Sony spending man power implementing SHA-1 when they could have spent that man power on fixing the moth eaten PDF viewer!

Well, they didn't implement SHA-1, they used existing libtomcrypt, so the process did not involve all that much man power. However, passing this "fix" under the cover of supposed improvements (what improvements?) is in my opinion unethical.

As far as I know Sony did not introduce a single noticeable improvement in their update. None of the wishes of the community were taken into account, but the desire to close the firmware to hacking was. Why? If Sony doesn't want to spend money and effort on improving the device, why not let the others help for free?

NatCh · 02-15-2007, 01:52 PM

This first update was apparently aimed at fixing mostly stability issues that they'd become aware of early after release, with added functions coming in future updates. Why any of that should affect the existing home brew is ... troubling, however. I haven't run across anything yet that gives me any notions of what's really going on with it, but if/when I'll point them out.

geekraver · 02-15-2007, 02:20 PM

Quote:

Originally Posted by scotty1024

MD5 is a hash, SHA-1 is a cryptographic digital signature that uses a RSA key pair to securely sign a digital document. If Sony had simply wished to protect against file corruption they would have used MD5. The only reason to use SHA-1 is to control the sourcing of the open source firmware.

Nope, SHA-1 is a hash algorithm, plain and simple (Secure Hash Algorithm 1).

scotty1024 · 02-15-2007, 03:32 PM

Please excuse my lack of precision: http://en.wikipedia.org/wiki/Digital...ture_Algorithm

The Sony Reader firmware is now using DSA/SHA-1 protection.

scotty1024 · 02-15-2007, 05:18 PM

Evidently things have advanced, we're now at 2^63. My back of the napkin sketch gets me down to 24 Virtex 5 chips for a max break time of 63 days.

Anyone willing to assemble 1024 chips could do breaks in 1.5 days.

http://en.wikipedia.org/wiki/Sha1

geekraver · 02-15-2007, 05:30 PM

I'm not sure there is any point in finding a hash collision. Hash collisions are potentially useful if you want to forge a digital signature, but its a kind of one-off attack, and requires padding of the data to be signed.

In this particular case what you want to do is fake a signature on a modified firmware. Padding probably isn't much of an option. You really need to break the DSA key. Doable at 1024 bits, but not cheap. Much better to just remove the signature check.

geekraver · 02-15-2007, 05:38 PM

If you go read that wikipedia article, you will see in fact: "In academic cryptography, any attack that has less computational complexity than a brute force search is considered a break. This does not, however, necessarily mean that the attack can be practically exploited."

I used to be a crypto guy but have been out of the field for the past 5 years. But if my memory serves me correctly, the biggest attack so far has been the discovery of some "neutral" data that can be inserted at block boundaries without affecting the final hash value. Potentially exploitable in rare situations but not generally useful.

scotty1024 · 02-15-2007, 06:25 PM

All the crypto texts all admonish everyone to remember the impact of Moore's Law. I just re-read Diamond Age and it has a reference to increasing key length to keep ahead of advances in computational capacity.

In the two years since the academic "break" we've gone from Virtex 4 to Virtex 5. The number of chips required to build a breaking engine has been reduced to the point that someone could put it on their Visa Gold card.

As with the number of x86 disassembler people vs ARM disassembler people, how many folks can program a Virtex 5 to attack SHA-1?

If you are interested, this paper speaks to using hash collisions to recover private keys: http://theory.csail.mit.edu/~yiqun/H...intVersion.pdf

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Hilarious Paper vs Ebook analysis	notyou	General Discussions	2	06-28-2010 04:39 PM
Flashing your EZ Reader Pro	Moo Strength	Astak EZReader	15	09-19-2009 06:30 PM
LIT generation -- binary analysis help with the last %0.1?	llasram	Workshop	12	12-13-2008 05:23 AM
Analysis of the De Tijd-project	TadW	News	1	04-17-2007 05:13 PM
PRS-500 Flashing the Reader via SD/MS	scotty1024	Sony Reader Dev Corner	29	04-09-2007 07:31 AM

02-15-2007, 09:24 AM	#32
Alexander Turcic Fully Converged Posts: 18,163 Karma: 14021202 Join Date: Oct 2002 Location: Switzerland Device: Too many to count here.	I've been following this discussion with interest, and what surprises me is that Sony is trying to lock down access to the device. It's just so counterproductive. It also reminds me of what iLiad hobby programmers went through - until iRex agreed, and supplied the necessary steps to access the iLiad.

02-15-2007, 09:29 AM	#33
igorsk Wizard Posts: 3,442 Karma: 300001 Join Date: Sep 2006 Location: Belgium Device: PRS-500/505/700, Kindle, Cybook Gen3, Words Gear	Well, I sort of can understand them... they're probably trying to prevent using unauthorized access to circumvent DRM. Except doing that on the device is not really practical - the desktop reading software is much easier to break into.

02-15-2007, 01:52 PM	#39
NatCh Gizmologist Posts: 11,615 Karma: 929550 Join Date: Jan 2006 Location: Republic of Texas Embassy at Jackson, TN Device: Pocketbook Touch HD3	This first update was apparently aimed at fixing mostly stability issues that they'd become aware of early after release, with added functions coming in future updates. Why any of that should affect the existing home brew is ... troubling, however. I haven't run across anything yet that gives me any notions of what's really going on with it, but if/when I'll point them out.

02-15-2007, 03:32 PM	#41
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	Please excuse my lack of precision: http://en.wikipedia.org/wiki/Digital...ture_Algorithm The Sony Reader firmware is now using DSA/SHA-1 protection.

02-15-2007, 05:18 PM	#42
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	Evidently things have advanced, we're now at 2^63. My back of the napkin sketch gets me down to 24 Virtex 5 chips for a max break time of 63 days. Anyone willing to assemble 1024 chips could do breaks in 1.5 days. http://en.wikipedia.org/wiki/Sha1

02-15-2007, 05:30 PM	#43
geekraver Addict Posts: 364 Karma: 1035291 Join Date: Jul 2006 Location: Redmond, WA Device: iPad Mini,Kindle Paperwhite	I'm not sure there is any point in finding a hash collision. Hash collisions are potentially useful if you want to forge a digital signature, but its a kind of one-off attack, and requires padding of the data to be signed. In this particular case what you want to do is fake a signature on a modified firmware. Padding probably isn't much of an option. You really need to break the DSA key. Doable at 1024 bits, but not cheap. Much better to just remove the signature check.

02-15-2007, 05:38 PM	#44
geekraver Addict Posts: 364 Karma: 1035291 Join Date: Jul 2006 Location: Redmond, WA Device: iPad Mini,Kindle Paperwhite	If you go read that wikipedia article, you will see in fact: "In academic cryptography, any attack that has less computational complexity than a brute force search is considered a break. This does not, however, necessarily mean that the attack can be practically exploited." I used to be a crypto guy but have been out of the field for the past 5 years. But if my memory serves me correctly, the biggest attack so far has been the discovery of some "neutral" data that can be inserted at block boundaries without affecting the final hash value. Potentially exploitable in rare situations but not generally useful.

02-15-2007, 06:25 PM	#45
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	All the crypto texts all admonish everyone to remember the impact of Moore's Law. I just re-read Diamond Age and it has a reference to increasing key length to keep ahead of advances in computational capacity. In the two years since the academic "break" we've gone from Virtex 4 to Virtex 5. The number of chips required to build a breaking engine has been reduced to the point that someone could put it on their Visa Gold card. As with the number of x86 disassembler people vs ARM disassembler people, how many folks can program a Virtex 5 to attack SHA-1? If you are interested, this paper speaks to using hash collisions to recover private keys: http://theory.csail.mit.edu/~yiqun/H...intVersion.pdf

Advert

Advert