Last week the SandForce 'automatic encryption' web page stated: “The SandForce SF-2000 SSD Processor solves this problem by embedding two encryption engines using AES-256 & AES-128 to protect the information it stores...” Now it reads, “The SandForce SF-2000 SSD Processor solves this problem by embedding two encryption engines using AES-128* to protect the information it stores...” The asterisk points to a note merely stating that “AES-256 support will be added in the future.”
The problem is that existing 256-AES doesn’t work. This doesn’t mean that there is no encryption – the 128-bit engine works just fine; but that’s all. It was discovered by an Intel audit of its own SSD-520 series. A note dated yesterday ‘updates’ the product description from AES-256 to AES-128. The Intel note does not discuss the problem; it simply indicates that the 128-bit engine still works, and adds that Intel believes “AES 128-bit encryption meets the data encryption requirements of most customers.”
Tech Report explains that the SandForce SF-2000 processors had retained a separate 128-bit engine to conform with US export controls. “The US government doesn't allow products with 256-bit encryption to be sold to some countries,” it notes. As a result, it would seem that the failure of the AES-256 engine merely causes encryption to fall back to the separate 128-bit engine. The solution to the AES-256 problem, however, apparently requires firmware changes – “a ‘manufacturing step’ rather than a re-spin of the silicon.”
Intel has already indicated that it will be offering refunds on its product until 1 October 2012. However, the fact that this problem has remained undetected for about a year says a lot about users’ attention to the detail of their own encryption – assuming, of course, that they use it at all.