That’s actually enough. If you have inlet temp, static pressure at the inlet, fan rpm and total pressure after the booster you have to use a fan map model and look up the pressure, but it can be calculated, and probably already is being calculated by the FADEC already and compared with the ideal map for condition monitoring. What you would do is, using the inlet temperature and rpm, you know how much pressure is being made by the fan and that allows you back calculate the free stream total pressure. Can be done pretty accurately (within a couple of knots) if you know the altitude.
And there are a couple of other ways of cross-checking the pitot based airspeed. Inertial reference has already been mentioned, how about force required to deflect control surfaces, relationship between pitch/power/vertical speed (static/gps based)? The problem I think lies not in coming up with new ways to calculate airspeed, but how do we design and certify the software to work out which is valid? Simple voting between the various systems would probably not do - the system would need to cross-check the values and trends from the individual sources and estimate the probability of particular airspeeds being reliable. But how do we then present all this information to the pilot? Does any further advancement of the automation imply we need to take the humans out of the loop?
The BEA report did not mention anything about GPWS messages. Were the final seconds of what went on in the cockpit simply omitted from the report, or does this suggest that the ADIRU faults also led altitude measurements to be automatically deemed invalid?