I think, like all security design choices this one came down to risk versus cost to do something different. The first question they need to ask is, what are they trying to protect?
Apple aren't interested in encrypting my music as it streams to the speakers, they're merely trying to protect a revenue stream which relies on only authorised manufacturers knowing the private key details.
The main threat to this is obviously exposure of the private key. So, where should they store the private key? They really only have a couple of (practical) choices imho.
1) On the device
2) On the Internet (yay - I didn't say cloud!)
If they store it on the Internet, effectively we're dealing with something akin to a Certificate Authority. An example process could be when you set up the devices they dial home with some form of key signing request which results in a key they can store on the device which is effectively unique to it but which can be validated by the AirPlay compatible software which has the public key for Apple's "CA". Google "web of trust" if you need more info, though it sounds like you understand this stuff.
That's quite a lot of overhead for something they are trying to sell in bulk and for about £60 each. So I guess they chose to store the key on the device and leave it static.
Next then, they evaluate ways in which they think the key could be exposed if it's on the device. Two main ones spring to mind:
1) Network software based attack
2) Physical attack
So now, what mitigation do they have in place for these?
In both scenarios the key, as I understand it, can be replaced by software updates, albeit this is reliant on end users to actually install the updates (not too big a problem - just bundle the update with some cool new feature they were developing anyway and most people would upgrade in a flash - no pun intended).
A physical attack would require specific equipment and knowledge, not necessarily complicated but let's face it, beyond the desire of most people to bother.
They also add the paperwork control by expressly forbidding people to "reverse engineer" the key.
If they really wanted to go to town, they could have made the AirPlay devices tamper-proof with something like the FIPS 140-2 standard but again, this seems massively excessive for a cheap consumer unit.
So, to answer your questions specifically:
Was this use of asymmetric key cryptography right? - I believe so, based on a risk analysis, similar perhaps to above.
How should it have been implemented to make such attack impossible? - maybe as I outlined with an online key signing or similar but really the point is, nothing is impossible when it comes to encryption. You need a key and it has to exist "somewhere", there's always a risk. What we are actually trying to do, like with all security design decisions, is mitigate the risk to the lowest acceptable business level.
HTH!
