# Delegation-Based Personal Data Processing Request
## 3 Delegation-Based Personal Data Processing Request Notarization Framework
### GDPR Compliance Audit Process
As the proposed framework inherits the integrity characteristics of BC, the data stored in the proposed framework can be used for GDPR compliance audits. The proposed framework secures countermeasures against major cyberattack threats and major attack threats that may occur in BC-based systems, as shown in Table 4 by satisfying security and functional requirements. #### 5.1.2 Function Analysis

The functions and properties of the proposed notarization framework were designed as per the design goal of Figure 5, and all the requirements of the notary framework for GDPR compliance audit were achieved. The proposed notarization framework receives a request for personal data processing from the DS, stores it in the ledger, notarizes it, and sends it to the DC by e-mail. In the event that the DC ignores, rejects, or delays the request without a good reason, it provides evidence to request legal sanctions, thereby guaranteeing the right of the DC to process their own data as defined in Chapters 12 to 21 of the GDPR. The proposed notarization framework assures an objective view on credibility by relaying and acting as a third party that notarizes requests and responses between the DS and DC and thus guarantees the reliability of records for GDPR compliance audits. In addition, the SPs need not modify the legacy personal data processing system or install a separate 3 rd party module; thus, it is highly applicable to the actual environment. Table 5 shows the results of analysis of the satisfaction of the proposed framework with the requirements of Figure 5.

Reasons for meeting each requirement of the proposed framework are as follows: \begin{table}
\begin{tabular}{c c c} \hline \hline
**Attack** & **Description** & **Countermeasure** \\ \hline Race attack & Send two conflicting transactions in rapid succession. & Since it is different from cryptocurrency, multiple recipients who receive the same transaction will not be harmed if their own transaction is canceled. \\  & & Data are encrypted with an encryption algorithm recognized for stability that uses a key length of 256 bytes or more, such as AES-256. Brute force attacks on 256-byte keys are almost statistically impossible with current technology. \\
51\% attack & After securing more than 50\% of the hash computing power among all nodes, the transaction information is manipulated. & Authorizes only SAs as BC network nodes and controls malicious participants. It is possible that the proposed network is a private BC. \\ DoS (Denial-of-Service) attack & Sending massive amounts of traffic paralyzes BC networks and nodes. & Revokes access and authority of a party that mounts a DOS on the system since they are known identities rather than anonymous. Checks authentication and authority in web service and BC network. Respectively, manages authority for smart contract functions by the user group. Allows only own transaction to be accessed. \\ Replay attack & Copy a transaction that was added to the BC in the past and replay it in the network to distort its operation. & Users submitting a transaction with a transaction certificate should include in the transaction a random nonce, that would guarantee that two transactions do not result into the same hash. \\ Sniffing and capture attack & Monitoring and capturing all data packets passing through network. & TLS is used for all network sections. Encrypts the main data of the transaction based on the session key. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Countermeasure to the proposed framework for major cyberattacks on BC. \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline
**A1** & **A2** & **A3** & **A4** & **B1** & **B2** & **B3** & **B4** & **B5** & **C1** & **D1** \\ \hline Y & Y & Y & Y & Y & Y & Y & Y & Y \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Analysis result of meeting the requirements of the proposed framework.