Oh come on ! This is 100% flame bait. None of those things are being advocated.
We have gone around the loop so many times having these same tired old arguments trotted out, over and over again. I just think it's time to move the debate forwards. I think it's a great, positive step forwards that content can be delivered to a device like the iPhone. The protection afforded by the device (stuff isn't saved to a disk/can't be ripped off) means content providers are happier in permitting it. The fact the stream is unencrypted is actually anathema to the whole discussion. I'm sure that, should the iPhone trials prove successful, as other devices from other manufacturers arrive on the market that offer similar "protection" and have a particular level of demand, we should hopefully see the trial expanded. But the BS about the biggest market first is... well, true. You must serve your biggest audience first, but that's not at the exclusion of others. Look at how a Windows iPlayer client was released first, then we've seen a Flash streaming version and now an iPhone version. And in fact, can't you now even access content on the Virgin Media platform ? That is progress however you may choose to view it. As evinced by others, content providers are not going to drop demands for content protection any time soon. By convincing ourselves they are, we actually do our cause a great disservice. It's only when the commercial realities start to illuminate the way, that we'll see a much greater sea change in the industry. But I think the iPlayer, in all it various guises has kick-started this. Patience is a virtue ! tom > > Are you advocating state censorship here? > Are you saying that discussion of security matters is > inherently wrong and bad? > Is analysis and discussion by independent 3rd parties not the > tried and tested method of verifying the security of a protocol? > > Does this mean I will be banned for posting a link to > http://portal.acm.org because it contains papers that detail > weaknesses in security systems? (Hmm, what would happen if I > wrote a paper on the BBC's security? It probably wouldn't be > published, journals don't often publish papers on stating the > obvious). > > I thought the BBC was supposed to support education and one > way of educating the next generation of security protocol > designers is to highlight the mistakes in previous protocols > and teach them how to avoid them. The problem with the BBC > system was either it assumed the User Agent was confidential > despite being transmitted plaint text to any site an iPhone > user visits. Or they assumed the attacker could not alter the > user agent. This is a common mistake, the attacker should be > assumed to be bale to transmit anything they like, be it > falsified data or even malformed packets. Attackers can craft > custom HTTP requests it's not difficult. > > Basically your trying to generate security from nothing. > What you need is some method of identifying "iPhone" that > can't be spoofed. > You where simply looking at information transmitted with the request. > This was prone to replay and was known to anyone who wanted it. > What you need is some cryptographic method. You need to use > something that is ON the iPhone, but only transmit data > available on it. > > A more secure method would be to transmit something derived from it. > A simple (naive) approach would be to use a one-way > cryptographic hash. (Denoted H) e.g. transmit H(T + SECRET),T > Where T is a timestamp. > > This reduces replay but it can still be used within a certain > time frame. > > Another method is to use a Nounce, (Number used ONCE) However > this requires the BBC to actually transmit the value. > The Nounce does not need to be secret however > BBC User > N__ ->____ > ___<-N,H(N+SECRET) > > But the BBC would have to remember the Nounce in a secure > way. Maybe maintaining state in a database server side. DO > NOT check the Nounce against a cookie as the attacker will > just send a cookie with a Nounce he has seen before. > > The only real problem is how to get the iPhone to run this > kind of code and where to derive the secret from. The code > could be implemented in Java or Javascript so all we need now > is to get the secret from somewhere. Unfortunately anything > your java/javascript can access so can anyone's and they can > just load there own code and transmit secret back over the > wire to their site. > > And of course the BBC can not provide SECRET from the server > as a non-iPhone would also get the secret. > > What you need is the iPhone to be able to do certain things for you. > I.e. it uses a key not accessible to remote sources. > Something like client side SLL certificate perhaps? > > Of course Authentication is pointless if you continue to > transmit the rest of the stream unencrypted, but that's trivial to do. > > Another approach is to go lower level, identify the OS by the > TCP/IP stack. However this breaks with certain proxying > techniques, isn't secure either and may be blocked by > firewalls (it often works by sending unusual traffic to see > how the client responds, many firewalls block unusual traffic > as it is seen as a threat). > > Admittedly this could all be academic if the regulators weigh in. > > Let's play a new game. Guess the fine. Guess how much the BBC > will be fined in the event it is fined! > > Anyway why *are* you trying to lock iPlayer to an iPhone > only? What about other mobiles? And don't give me that BS > about biggest platform first, turn off your checking and it > works on all MP4 compatible mobiles. > > -- > Computers are like air conditioners. Both stop working, if > you open windows. > -- Adam Heath > - > Sent via the backstage.bbc.co.uk discussion group. To > unsubscribe, please visit > http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. > Unofficial list archive: > http://www.mail-archive.com/[email protected]/ > - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
