# Secure Data Sharing in Federated Learning through Blockchain-Based Aggregation
## 3 EIFFeL Framework and Security Analysis
### Scheme Architecture and Workflow
\(\mathcal{S}\) requests the shares (in clear) from \(\mathcal{C}\) for the clients who flaged it (e.g., \((\{\mathbf{u}_{i,1}\}||(i,\overline{\mathbf{u}}_{i,1}))\) generated by \(\mathcal{C}_{i}\) for \(\mathcal{C}_{i}\)), and verifies the contents with the relevant check string (e.g., \((\{\mathbf{u}_{i,n}\}||(i,\overline{\mathbf{u}}_{i,1}))\), \(\mathcal{C}_{i}\)) is marked as malicious; otherwise, \(\mathcal{C}_{i}\) is instructed to use the released share for its computations. 3. Announces the updated \(\mathcal{C}^{*}\) on the public bulletin board \(\mathcal{B}\). 4. Generation of proof summaries by the clients: - Announces a random number, \(r\in\mathbb{F}\), on the public bulletin board, \(\mathcal{B}\). Each client \(\mathcal{C}_{i}\): - Generates a summary, \(\sigma_{ij}\), of the proof string, \(\pi_{ij}\), based on \(r\) and SNIP, \(\forall\mathcal{C}_{j}\
otin\mathcal{C}^{*}\), and publishes it on the public bulletin, \(\mathcal{B}\). 4. Verification of proof summaries by the server: - Collects and verifies all proof summaries from \(\mathcal{C}\setminus\mathcal{C}^{*}\) with \(robustRecon(\cdot)\), and updates \(\mathcal{C}^{*}\) based on the result. 5. Each client \(\mathcal{C}_{i}\): - If \(\mathcal{C}_{i}\in\mathcal{C}^{*}\), it can initiate a dispute by transmitting the transcript of the reconstruction of \(\sigma_{i}\). If any successful dispute occurs, all clients abort the protocol, since the server, \(\mathcal{S}\), is considered malicious by withholding the valid updates. - Otherwise, it sends the aggregate \(\mathcal{U}_{i}=\sum_{\mathcal{C}_{j}\in\mathcal{C}^{*}}\), \(\mathbf{u}_{ij}\) to the server \(\mathcal{S}\). 6. **Model parameter aggregation**: Server \(\mathcal{S}\) recovers the final aggregate, \(\mathcal{U}\gets robustRecon(\{i,\mathcal{U}\})_{\mathcal{C}_{i}\mathcal{C}^{*}}\), and sends it to clients. 7. **Model update**: Each client, \(\mathcal{C}_{i}\), resets its local model with the parameters, \(\mathcal{U}\). Figure 4: One iteration/epoch of the EIFFeL scheme. It should be corrupt-resistant against all entities, including the server, clients, and other attackers. The data should not be changed, deleted, or manipulated by malicious entities in any manner. * It should be able to validate the identities of clients (and the server) according to some public key infrastructure (PKI). By default, some PKI information should be stored on the bulletin board so that it can validate the identity claims of its users. * It should be able to establish a secure channel with its users so that the integrity and authenticity of the users' data can be guaranteed during the transmission. Public bulletin boards have been used in many scenarios [25], and they can certainly play an important role in FL. However, how to achieve the last two guarantees is not trivial. In particular, the involvement of a PKI means that there will be another fully trusted third party. The trust relationship among all the entities in the solution needs to be clarified in order to guarantee that all threats are properly present. Secondly, there is some ambiguity in remark 1 of reference [16]. It states that EIFFeL prevents the server from \"Mark the input of an honest client as invalid and include it in the final aggregate\". In fact, the server can manipulate the final aggregate without being noticed, in step 3 of the model parameter aggregation. This is equivalent to invalidating the input of honest clients, as the final aggregate no longer appears to be an aggregation of inputs from all honest clients. This implies that EIFFeL cannot guarantee the integrity of the aggregate in the presence of a malicious server. Note that this observation does not conflict with the desired security properties, i.e., against the server, only privacy is expected. In addition, if the server deviates from the protocol, Lemma 4 from [16] will not hold. This lemma states that \"The final aggregate must contain the updates of all honest clients or the protocol is aborted\".