因為好讓數據好轉換成電子的
8/ 要簡單講一下嗎
15 可以說到我們會用到大量的密碼學
確定我們的板子可以承受那些攻擊?

internetbase 是不是同一個人 internet危險
machinebase 沒有任何其他方案是可以達到目前要求的（跟其他比較起來家安全）

machine base 要寫成other machinebase
other machinebase **沒辦法解決信任問題(核心目標)**
準備講稿 ！！！

- 夠快 tally
- 不要雲端 (政府接受度)
- 夠安全
- 公開稽核 (區塊鏈)
加密簽名那些要想辦法表達出來

一頁背景 exist sol
兩三頁 procedure protocol (ureka要講)
一頁 每一個machine 安全
demo
一頁 前面講的要夠快不要雲端夠安全

印度很爛 我們不是 based on 那個
還有在講其他的缺點的時候要講清楚(沒有record和投票者身分認證)

---
11/2

3. 黃色的字好醜，全部的問題我們都有解決嗎
4. 講開發板不要講板子，source code 這個我沒寫？
6. 突然幹一個ureka覺得怪怪的

## ureka 和一些其他的加密技術應該要分另外一個地方講

## Design（需要加上一些圖）

### Assumption
區塊鏈EID系統：一套個人身份驗證系統每個人都有屬於自己的公鑰以及密鑰，並且會有自己有關的相關事件記錄在區塊鏈上面
區塊鏈的驗票系統：當admin把ureka的r ticket上傳之後，需要有基於區塊鏈的所開發出來用來查看該r ticket是否為合法的。


Blockchain EID System: A personal identity verification system where each individual has their own public and private keys, with related events recorded on the blockchain.

Blockchain Ticket Verification System: When the admin uploads a specific “Ureka R ticket,” a blockchain-based solution is required to verify if the r ticket is valid.

### Intro
為了設計一套安全並且可靠的電子投票系統，我們用了三個不同的角色去呈現出我們設計的系統分別是投票機，管理員，以及投票者。並且將整個投票分成了三個階段設定，投票，結算。

To design a secure and reliable electronic voting system, we have defined three distinct roles to represent our system: the voting machine, the administrator, and the voter. The voting process is divided into three stages: setup, voting, and tally.

##### voting machine
一台可信任的機器主要負責投票的整體邏輯，透過ureka protocol來確保存取資料的權利。會有自己的公鑰以及密鑰，來進行一些後續所需的加密需求。

A trusted machine is primarily responsible for managing the overall voting logic, ensuring data access rights through the Ureka protocol. It possesses its own public and private keys to handle necessary encryption requirements.
##### administrator, admin agent
管理員是一場投票活動中最重要的人物，他擁有一台admin agent可以幫他用他的公鑰以及密鑰來做加解密的動作。admin擁有對voting machine的控制權，在投票的過程會透過admin agent對voting machine做設定以及結算的功能。以及它能賦予user agent有能力去進行投票的動作。

The administrator is the key figure in a voting event. They have an admin agent that enables encryption and decryption operations using his public and private keys. The admin has control over the voting machine through the admin agent to set configurations and tally results during the voting process. Additionally, the admin can authorize the user agent to vote by voting machine.
##### voter, voter agent
代表投票人，投票人擁有一台voter agent可以幫他用他的公鑰以及密鑰來做加解密的動作。voter需要經過admin允許才能到voting machine上面執行投票的動作。

Representing the voter, each voter has a voter agent that enables encryption and decryption operations using their public and private keys. The voter must receive permission from the admin before they can execute voting actions on the voting machine.
#### 購買voting machine
##### init
voting machine 在製造商那便被生產出來後製造上會生一張ureka 的init 票給voting machine 將其初始化，此時這台機器的owner是製造商。

Once the voting machine is manufactured, the manufacturer issues a "Ureka init U ticket" to initialize the machine. At this point, the owner of the machine is the manufacturer.

##### ownership
在admin購買voting machine之後，製造商就會透過ureka 的 ownership ticket將機器的所有人轉給admin。

After the administrator purchases the voting machine, the manufacturer transfers ownership to the admin through a "Ureka ownership U ticket."

#### 投票
##### 設定
admin會先透過區塊鏈上面的EID系統拿到這次投票的相關設定（像是id,符合資格的投票人，候選人，投票的持續時間等等），
並透過ureka 的self access ticket去將所有設定輸入給voting machine此時投票就正式開始。

The administrator first gets the relevant settings for the current vote through the blockchain-based EID system (such as the vote ID, eligible voters, candidates, voting duration, etc.). Using the "Ureka self-access U ticket," the administrator inputs all configurations into the voting machine, officially starting the voting process.
##### 投票
voter會先去和admin認證身份，確認有資格可以投票後，admin會發給voter一張ureka的 access ticket，voter便能憑藉這張ticket去和voting machine進行投票的操作，但要確定使用ticket的時間是在voting machine的投票時間裡面。
The voter first authenticates with the administrator to confirm their eligibility to vote. Once verified, the admin issues the voter a "Ureka access U ticket," which allows the voter to interact with the voting machine and cast their vote. However, it is essential that the ticket is used within the designated voting period set on the voting machine.
##### 結算
再選局時間結束之後，admin會透過ureka 的self access ticket去進行結算的操作，之後voting machine 便會將投票結果透過Ureka R ticket傳回給admin。並且在talley之後就可以開放permissionless ticket的查詢。admin會將帶有選局結果的r ticket上傳回區塊鏈讓大家都可以驗證。

After the voting period ends, the administrator uses the "Ureka self-access U ticket" to finalize the tallying process. The voting machine then sends the voting results back to the administrator through a "Ureka R ticket." The administrator uploads an "Ureka R ticket" containing the election results to the blockchain, allowing everyone to verify the outcome. Once tallying is complete, permissionless ticket queries are enabled.
##### permissionless ticket
此ticket是我們基於ureka系統另外設計的特殊ticket可以讓任何人得到一些voting machine公開的資料，但並沒有更改資料的權利。
在admin結算過後voter可以透過voter agent自己產生permissionless ticket去和voting machine調取這次選舉的結果以及初始設定。此設計是為了防止admin操控投票的問題。

This ticket is a specially designed ticket within the Ureka system, allowing anyone to access certain public data from the voting machine without the authority to modify it. After the administrator completes the tally, voters can use their voter agent to generate a permissionless ticket, enabling them to retrieve the election results and initial settings about this election from the voting machine. This design aims to prevent potential manipulation by the administrator.

## Implementation

### Voting Machine (M2354)

The voting machine is implemented on the NuMicro® M2354 microcontroller, chosen for its advanced security features, including TrustZone and hardware-backed cryptographic acceleration. This machine is crucial for secure vote storage, communication, and processing in the e-voting system.

1. **Initial Simulation Environment**
We first simulated the voting machine on Ubuntu using C++, incorporating the mbedTLS library for cryptographic functions and the nlohmann JSON library for data handling. This simulation phase allowed us to validate the functionality and security aspects of our voting logic before deploying it to the embedded system. Unit tests are also done in this phase to make sure the correctness of our implementation.

2. **Embedded Implementation**
After successfully validating the design in the simulation, we transitioned to embedded C++ for implementation on the M2354. Given the memory constraints of the microcontroller, we utilized the built-in crypto module for Diffie-Hellman key exchange and ECC-based operations, including encryption, decryption, and key generation. Additionally, we implemented a custom JSON library tailored to our needs, as the libraries used in simulation were too large for the board's limited resources.

3. **TrustZone Secure Environment**
TrustZone technology on the M2354 creates a secure environment that isolates critical processes, such as vote handling and cryptographic operations, from non-secure functions. Sensitive data, including private keys and stored ballots, resides within the Secure World, reducing vulnerability to external attacks and ensuring that only authorized processes can access confidential information.

4. **UREKA Protocol for Controlled Communication**
The voting machine integrates the UREKA protocol to manage secure communication with authorized devices. Communication is strictly controlled through U-Tickets, which are digitally signed by the voting machine’s owner (the Admin Agent). Only authenticated devices presenting a valid U-Ticket can issue commands, protecting the voting machine from unauthorized access. This ensures that only verified devices—Admin or User Agents—can interact with the voting machine for tasks like configuring, voting, and tallying.

5. **Secure Boot and Firmware Integrity**
To prevent tampering at the firmware level, the M2354 employs secure boot, ensuring that only authenticated firmware can run on the device. This step adds a layer of physical security by guaranteeing that the voting machine operates with trusted code, preventing unauthorized modifications that could compromise election integrity.

By leveraging TrustZone, hardware-accelerated cryptography, the UREKA protocol, and secure boot, along with a custom implementation tailored for embedded systems, the M2354-based voting machine provides a robust, high-security environment for e-voting.

### Admin agent/ User agent (Android phone)

Both the Admin and User Agents are implemented as Android applications, with each app running on a separate Android phone. These applications serve distinct roles in the e-voting system: the Admin Agent is responsible for initializing the voting process, managing voter lists, and tallying results, while the User Agent represents individual voters, allowing them to cast votes securely.

1. **UREKA Protocol Integration**
Both agents implement the UREKA protocol to enable secure and verifiable communication with the voting machine. U-Tickets, which are digitally signed messages, are used by each agent to authenticate requests to the voting machine. The Admin Agent uses U-Tickets to send configuration and tally requests, while the User Agent uses them to cast votes. These tickets include ECC-based signatures generated within the app, ensuring that only authorized requests are processed by the voting machine.

2. **Cryptography library with spongycastle**
Each agent manages a unique ECC key pair for cryptographic operations, ensuring secure communication with the voting machine. SpongyCastle, a widely-used Java cryptographic library, is integrated into the app to support Diffie-Hellman key exchange algorithm and ECC-based operations such as encryption, decryption, and signature generation, ensuring data integrity throughout the voting process.

3. **JSON Handling with GSON**
JSON format is used to structure data in U-Tickets and responses, making data handling efficient and easy to parse. We utilize GSON, a Google library for JSON processing, to serialize and deserialize the JSON messages used in U-Tickets, such as user credentials, vote choices, and authentication responses. This integration simplifies message formatting for seamless communication between devices.

4. **Unit and Integration Testing**
To ensure reliability, both apps undergo thorough testing. JUnit is used to conduct unit tests for cryptographic functions, UREKA protocol ticket creation, and JSON processing. Additionally, integration tests verify secure communication flows between the Admin/User Agents and the voting machine, ensuring that only valid and authorized messages are accepted.

By combining the UREKA protocol, ECC encryption, and efficient JSON handling within Android, these apps provide secure, efficient, and user-friendly interfaces for both admin and voter functions in the e-voting system.

### Communication

The voting machine utilizes a Bluetooth Low Energy (BLE) module for secure communication with authorized devices, such as Admin and User Agents. This choice supports low-power consumption while maintaining a reliable connection for critical interactions.

1. **BLE as the Communication Protocol**
The BLE module facilitates short-range communication, allowing direct and secure interactions without reliance on internet connectivity. This approach significantly reduces the risk of remote attacks and enhances the system's overall security.

2. **UREKA Protocol for Secure Messaging**
Communication is governed by the UREKA protocol, which requires authenticated devices to present a valid U-Ticket signed by the voting machine’s owner (the Admin Agent) before any operation can be performed. This ensures that only authorized devices can communicate with the voting machine.

3. **Secure Data Transmission**
To protect sensitive information exchanged during communication, all data transmitted between the voting machine and connected devices is encrypted by the key generated from Diffie-Hellman Algorithm. This safeguards the integrity and confidentiality of the voting process.

The integration of BLE and the UREKA protocol provides a robust framework for secure and efficient communication within the e-voting system, ensuring that only authenticated devices can interact with the voting machine.

### Testing Implementation

#### Integration Testing

Integration testing is a critical phase where we evaluate the interactions between various components of the e-voting system to ensure they function together as intended. In this phase, we focused on the following aspects:

1. **Component Interaction**
We tested the communication between the voting machine (M2354) and the Admin/User Agents (Android devices) using the Bluetooth Low Energy (BLE) module. This involved verifying that the UREKA protocol was correctly implemented, ensuring that only authenticated devices could communicate with the voting machine through signed U-Tickets.

2. **Functional Scenarios**
Various functional scenarios were simulated to assess the system's behavior under different conditions, including:
- **Valid Access Attempts:** Ensuring that authorized devices could successfully initiate communication, perform ID verification, and cast votes.
- **Invalid Access Attempts:** Testing the system's response to unauthorized access, such as attempting to vote with an invalid ticket or from a non-authenticated device. This validated that the system effectively blocked unauthorized interactions.
- **Forbidden Attempts:** Testing the system's response to re-init the machine. Since in our design, device could only be initiallized once. This make sure the ownership of device couldn't be changed easily.

3. **Data Integrity and Accuracy**
We checked that the data transmitted between devices remained intact and accurate throughout the communication process. This included validating the encrypted messages and ensuring that votes were correctly recorded and tallied by the voting machine.

4. **Error Handling**
We examined the system's robustness by intentionally introducing errors, such as invalid ticket signatures or interrupted communication, to evaluate how well the system handled these scenarios. This testing ensured that appropriate error messages were generated and that the system could recover gracefully.

By focusing on integration testing, we ensured that the e-voting system is reliable, secure, and capable of functioning effectively in real-world voting scenarios.

### 教授
1. 資訊太少了 標題需要破題(資訊給多億點 需要一個新的名字
強調別人的問題 來做展開(最一開始)
- 做票
- 隱私性
- 很快
然後為啥UREKA可以解決這個問題 為什麼開發板(TEE)可以解決這個問題
2. 簡單講一下就好 大家都知道
3. 問題回到上面提到的作票 隱私性等等
- 將其他國家的投票帶到上面的問題
- 不用強調網路攻擊
- 投票細節也不用講太多大家基本都知道
4. 跳得太快，不知道我們要解決什麼問題
- 我們這邊應該說我們要怎麼樣解決上面提到的問題
- 再來寫說裡面的實作
- 不要說起來讓大家以為只有這個板子能做到我們需要的事情
- 應該以他開好符合所以我們才選
5. 一樣是前面沒有講為什麼要這樣
- 需要講這個流程為什麼
- 像是要講為什麼需要分三個
- 為什麼VOTING MACHINE 需要隔絕網路攻擊
- ADMIN不會權力過大嗎 三權分立
6. **都是陳述流程 應該著重為什麼要這樣設計。**
有三權分立的圖講述為什麼要這樣設計
7. 為什麼要這樣設計

8. 這邊要強調整個流程USER角度來講是簡單的