All of this higher level HCI and API shiz rests (in the embedded world) on a set of registers which are usually documented in the daatsheet. By manipulating these registers, the developer can make the IC do anything it is capable of doing: it is the ultimate API, and there is almost no means in code of making the hardware do anything except by this means.
So any 'shadow' API is not really of any consequence in embedded, because it all boils down to these registers, which we can perfectly well view or manipulate.
Espressif, as well as all other manufacturers of such BLE enabled SoCs provide at least some parts of their RF stack as precompiled binary.
However, Espressif took the decision to deliberately not publish the registers used at lowest level to configure and command the RF peripheral on the IC. All other manufacturers I am aware of publish these registers, just like all the others.
Ultimately this minor obfuscation offers no additional security benefit, nor does it create any security loophole above any that exist on any other chipset.
This is an absolute non-issue, as others have commented.
Even without domain-specific knowledge, we can see this is all nonsense: 'Allow attackers to carry out impersonation attacks' - the same thing that can be done with any number of legitimate and useful applications designed for developing with BLE, available on Android marketplace :*)
On any embedded platform which allows low level access to a radio transciever of any kind, it is possible to exercise all functionality, which will include various possible attacks. The only thing which prevents this in the industry at present is obfuscation, which most manufacturers (other than Espressif) dont bother with.
Take Nordic for example, who make probably the best and most widely used/respected BLE chipset: the full functionality of the transciever can be used via a relatively small set of registers, which are fully documented. Nordic supply a BLE stack, but you can perfectly well write your own instead, meaning that you can deliberately or accidentally abuse all aspects of the protocol.
Even at physical level, one can easily conduct simple jamming attacks, by broadcasting full power carrier signal on the BLE advertising channels.
None of this naughtiness is a security flaw. BLE and other wireless protocols in common use are well designed to be resistant to jamming, and the physical implementation of the radios on various SoCs available currently are limited: you cant put out 10 watts of hash over 82 channels at once, because the silicon doesnt support it.
You cant even 'sniff' BLE traffic in a real sense, because the silicon on requires a significant number of bytes of 'address' in order to capture any meaningful packet data from ambient noise.
Here is C code, as a fun example, to broadcast full power carrier on any channel, from Nordic NRF52. This is absolutely documented and useful for testing (for example emissions).
// set channel to number between 0 and 100
int channel = 0;
nrf_radio_shorts_set(0);
nrf_radio_int_disable(~0);
nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED);
nrf_radio_task_trigger(NRF_RADIO_TASK_DISABLE);
while (!nrf_radio_event_check(NRF_RADIO_EVENT_DISABLED)) {}
nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED);
Espressif, as well as all other manufacturers of such BLE enabled SoCs provide at least some parts of their RF stack as precompiled binary. However, Espressif took the decision to deliberately not publish the registers used at lowest level to configure and command the RF peripheral on the IC. All other manufacturers I am aware of publish these registers, just like all the others. Ultimately this minor obfuscation offers no additional security benefit, nor does it create any security loophole above any that exist on any other chipset.