One explicit goal of the EUDI wallet is to be published under open source licenses. Our interpretation is that while this does not aim at backend/server implementations, all the relevant components of the smartphone side of the EUDIW, and particularly those providing the major security and privacy guarantees, shall be open source.
Unfortunately, many existing certification schemes make it very hard to reach the higher levels of certification (such as EAL4+AVA_VAN.5) that will supposedly be required for LoA High with completely open source implementations due to the penalization of open source software and/or hardware designs through the implied assumption that attackers have a distinct advantage with open source components. This may have been true(er) when those certification schemes were originally developed, but practical experience over the decades has shown that well-resourced attackers do not find closed source components to be a hard barrier (as evidenced most impressively by the plethora of attacks against various Microsoft Windows and iOS subsystems, among other proprietary systems). Furthermore, reverse engineering software or hardware is a one-time cost that amortizes well for organized attack teams.
The ARF should therefore be adapted so that certification schemes applied to EUDIW components shall explicitly not penalize open source implementations to remain compatible with the (correctly) stated goals.
One explicit goal of the EUDI wallet is to be published under open source licenses. Our interpretation is that while this does not aim at backend/server implementations, all the relevant components of the smartphone side of the EUDIW, and particularly those providing the major security and privacy guarantees, shall be open source.
Unfortunately, many existing certification schemes make it very hard to reach the higher levels of certification (such as EAL4+AVA_VAN.5) that will supposedly be required for LoA High with completely open source implementations due to the penalization of open source software and/or hardware designs through the implied assumption that attackers have a distinct advantage with open source components. This may have been true(er) when those certification schemes were originally developed, but practical experience over the decades has shown that well-resourced attackers do not find closed source components to be a hard barrier (as evidenced most impressively by the plethora of attacks against various Microsoft Windows and iOS subsystems, among other proprietary systems). Furthermore, reverse engineering software or hardware is a one-time cost that amortizes well for organized attack teams.
The ARF should therefore be adapted so that certification schemes applied to EUDIW components shall explicitly not penalize open source implementations to remain compatible with the (correctly) stated goals.