# Delegation-Based Personal Data Processing Request
## 3 Delegation-Based Personal Data Processing Request Notarization Framework
### GDPR Compliance Audit Process
The analysis was conducted to determine whether the functions and properties of the proposed notarization framework meet the following requirements. #### 5.1.1 Security Analysis

The proposed framework was designed as per the design goal of Figure 5, and all the security requirements of the notary framework for the GDPR compliance audit were

Figure 12: A transaction in a saved block viewed by peers. achieved. Results of analysis of the satisfaction of the proposed framework with the security requirements are as follows:

* Data security: In the proposed framework, a transaction key was generated by automatically combining the DS's ID and timestamp in the chaincode when creating a request transaction, and the service provider URL of the DC and timestamp when creating a response transaction. The transaction was stored including the signature created by the private key of the creator. Furthermore, when searching for a stored transaction, the proposed framework compares the user's information (Uid, SPurl) with the stored transaction key in the chaincode. When the auditor desires to query the transaction of the DS and DC, the proposed framework checks whether the auditor has been granted the inquiry right by the DS and DC and that the authorization period is valid; then, the information (Uid, SPurl) of the approvers DS and DC is compared with the stored transaction key. The transactions are linked to each other using a hash algorithm in blocks, and their integrity is guaranteed due to it being copied and distributed to each peer in the BC network. The request and response contents that may contain sensitive personal data are encrypted and input by creating a symmetric key-type session key for each transaction in the application, and the session key is stored for each transaction in the application database. The creator, receiver, and auditor with inquiry authority can decrypt the data retrieved from the BC by inquiring the session key for each transaction. Thus, even if a transaction is exposed to an unauthorized peer in the BC network, the data cannot be decrypted unless the service is accessed through authentication in the proposed framework. * Authentication and authorization: HLF provides Fabric CA as the default CA. Fabric CA is a public key infrastructure (PKI) based and used to generate X.509 digital certificates. All entities in the HLF must be identified by a digital ID before interacting with the BC network. An X.509 digital certificate contains key and related information of an entity and is either signed by the Fabric CA or self-signed. When implementing the proposed framework, we set the initialization value in the docker-compose-ca.yaml file and started Fabric CA using Docker. Furthermore, before interacting with the proposed framework, all entities were registered with the CA server using Fabric CA client or Fabric SDK and received the key and certificate. HLF provides an infrastructure management mechanism called \"policy.\" Fabric policies represent the manner in which the members agree to accept or reject changes to a network, channel, or smart contract. We set policies in configtx.yaml to control all the actions each member desires to perform on the Fabric network. For example, although the DS and DC organizations allowed access to the transaction registration chaincode, the auditor group SA organization was allowed access only to the audit inquiry chaincode, while access to the notary group SA organization was not granted. * Prevention of denial: In the proposed framework, transactions were created as blocks through the signature of the creator's private key, stored in the ledger, and shared in the BC network. In addition, by ensuring that the peers acting as the notary of the block are composed and operated only by SAs, the integrity and reliability of the stored data was increased to prevent the repudiation of notarized data. * Accountability: In the proposed framework, request and response transactions were stored in the form of {who, when, who, what}.