On 14/03/2008, James Cridland <[EMAIL PROTECTED]> wrote: > I'm a BBC senior manager; but posting personally as a fan of Backstage.
I thought I recognised the name. > It puts us (those that care about Backstage) in a really difficult position > if it's used to share information on ways to get around content-restrictions > on a BBC service. > > I don't want to see the end of the Backstage unmoderated mailing list. > Posting this type of information threatens its future. 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]/
