Liang’s Bolg

前言 在传统的电子邮件系统中，如果 Alice 想给 Bob 发送一封加密邮件，需要使用 Bob 的公钥加密来加密邮件，进而需要一个公钥证书颁发机构（Certificate Authority，CA）对系统中的公钥一一生成证书，用户才可以放心地使用公钥；此外这种加密方案缺乏语义性，即加密所用的公钥是一个群元素。可以看出，公钥证书的管理给系统带来了存储和计算方面的巨大开销。 为了解决这一问题，在1984年，著名密码学家 Shamir 提出是否可以构造一个公钥加密方案，它可以使用任意的字符串作为公钥加密数据。随后，身份基加密（Identity-Based Encryption，IBE）应用而生，在使用身份基加密的电子邮件系统中，当 Alice 想要给 Bob 发送邮件时，只需使用 Bob 的邮件地址“bob@company.com”作为公钥即可生成密文，Bob 向私钥生成中心（Private Key Generator，PKG）请求对应于自己邮件地址的私钥，随后使用该私钥便可完成解密。在该密码体制内，无需管理公钥证书，且任意字符串都可以作为加密公钥。 2003年，Boneh 和 Franklin 提出了第一个完全实现身份基加密的文章详。强调完全实现，是因为在这之前的身份基加密方案要么是无法抵御用户合谋攻击，要么需要抗篡改的硬件支持。本文提出了在随机预言机模型（Random Oracle Model，ROM）下可以抵御选择明文攻击的适应性安全（Chosen plaintext security，IND-CPA）的方案和可以抵御选择密文攻击的适应性安全的方案（Chosen ciphertext security，IND-CCA）。 预备知识 待补充 身份基加密定义 本节首先给出身份基加密的算法定义，随后对其正确性和安全模型进行描述。 算法定义 一个身份基加密方案$\epsilon$包含以下4个算法： $\mathsf{Setup}(k)\rightarrow (\mathsf{mpk,msk})$: 系统初始化算法输入安全参数$k$，输出系统主公钥$\mathsf{mpk}$和主私钥$\mathsf{msk}$； $\mathsf{Extract}(\mathsf{mpk},\mathsf{msk},\mathsf{ID}) \rightarrow d$：密钥生成算法输入系统主公钥$\mathsf{mpk}$、主私钥$\mathsf{msk}$、和用户身份$ID$，输出用户$ID$的私钥$d$； $\mathsf{Encrypt}(\mathsf{mpk},ID,M)\rightarrow C$：加密算法输入系统主公钥$\mathsf{mpk}$、用户$ID$和明文$M$，输出密文$C$； $\mathsf{Decrypt}(\mathsf{mpk},d,C)\rightarrow M$：解密算法输入系统主公钥$\mathsf{mpk}$、用户$ID$的私钥$d$和密文$C$，输出明文$M$。 正确性：给定安全参数$k$，对于任意用户$ID$和明文$M$，如果$(\mathsf{mpk},\mathsf{msk})\leftarrow \mathsf{Setup}(k)$，$d\leftarrow \mathsf{Extract}(\mathsf{mpk},\mathsf{msk},ID)$，$C\leftarrow \mathsf{Encrypt}(\mathsf{mpk},ID,M)$，则 $$\Pr{[\mathsf{Decrypt}(\mathsf{mpk},d,C)=M]}=1.$$ 安全模型 适应性选择明文安全（Chosen plaintext security，IND-CPA） 称一个IBE方案是IND-CPA的，如果对于任意多项式时间的敌手$\mathcal{A}$，在下述的IND-CPA游戏中获胜的概率是可忽略的： 初始化：挑战者$\mathcal{C}$选取一个安全参数$k$并运行$\mathsf{Setup}$算法，将系统主公钥$\mathsf{mpk}$发送给$\mathcal{A}$，自己保留主私钥$\mathsf{msk}$； 阶段1：$\mathcal{A}$发起对挑战者的询问$q_1,\dots,q_m$，其中$q_i$是下述询问： $\mathsf{Extract_q}(ID_i)$：$\mathcal{A}$选择一个$ID_i$，挑战者返回私钥$d_i$给敌手； 挑战阶段：$\mathcal{A}$选择两个长度相同的消息$M_0$和$M_1$和一个身份$ID$，$\mathcal{C}$发送相应的密文$C\leftarrow \mathsf{Encrypt}(\mathsf{mpk},ID,M_b)$给$\mathcal{A}$，其中$b$随机选自于 ${0,1}$； 阶段2: $\mathcal{A}$发起对挑战者的询问$q_{m+1},\dots,q_n$，其中的询问和阶段1相同； 猜测：$\mathcal{A}$输出一个猜测$b^\prime$，如果$b^\prime=b$，那么$\mathcal{A}$赢得游戏； 我们定义敌手$\mathcal{A}$的优势为 $$\text{Adv}_{\mathcal{A}}^{\text{IND-CPA}}(k)=|\Pr{[b^\prime=b]}-1/2|.$$ 称IBE方案$\epsilon$是适应性选择明文安全的，如果对于任意多项式时间的敌手$\mathcal{A}$，$\text{Adv}_{\mathcal{A}}^{\text{IND-CPA}}(k)$是可忽略的。 ...

背景与定义 属性基加密（ABE, Attribute-Based Encryption） 和 可搜索加密（SE, Searchable Encryption） 是密码学中两大关键技术： ABE 允许数据基于用户属性（如角色、部门、安全等级）实现细粒度访问控制，加密数据仅能被满足特定属性策略的用户解密。 SE 支持在加密数据上直接执行关键字搜索，无需解密，解决了云端数据隐私与检索效率的矛盾。 ABKS（Attribute-Based Keyword Search） 将两者结合，实现基于属性的关键字搜索：用户仅在其属性满足访问策略时，才能对加密数据执行关键字检索。其核心目标是在保障数据机密性、访问控制的前提下，支持高效的关键字搜索功能。 系统模型与关键技术 系统角色 数据拥有者（Data Owner）：加密数据并指定访问策略（如 (医生 AND 科室A) OR 急诊权限）。 云服务器（Cloud Server）：存储加密数据，并根据用户请求执行搜索操作。 数据用户（Data User）：提交关键字搜索请求，需通过属性授权获取搜索令牌。 算法定义 安全需求与挑战 安全模型 密文不可区分性（IND-CPA）：攻击者无法从密文中推断明文信息。 关键字隐私性：云服务器无法获知搜索关键字的具体内容。 抗合谋攻击：多个用户无法联合属性集突破访问策略限制。 主要挑战 效率与计算开销：双线性对和复杂策略导致加密/搜索延迟较高。 动态策略更新：如何在策略变更时避免重新加密全部数据。 隐私泄露风险：搜索模式可能暴露用户意图。 代表性工作 VABKS: Verifiable attribute-based keyword search over outsourced encrypted data 单关键字、私有可验证、不保护访问策略、不抵御 KGA、单策略、无解密 Protecting your right: Verifiable attribute-based keyword search with fine-grained owner-enforced search authorization in the cloud 单关键字（可拓展为合取）、私有可验证、不保护访问策略、不抵御 KGA、单策略、无解密 ...

灵活撤销 Direct revocation The DO encrypts files with a separate revocation list (as a policy), preventing revoked users from decrypting the ciphertext while non-revoked DUs remain unaffected. However, all DOs must maintain an ever-growing revocation list, increasing ciphertext size over time. Limitations: Ciphertext size is linearly increasing with the number of revoked users. Users are represented with a unique ID. No anonymous. Indirect revocation A timestamp is embedded in the ciphertext, and the KGC periodically updates the private keys of non-revoked DUs. Revoked DUs cannot obtain valid key updates to decrypt future ciphertexts. Q: The revoked users can decrypt past ciphertexts they were originally allowed to. ...

20241201 Aggregating knowledge graphs from multiple users 抗量子ABKS VIPMatch: Verifiable, Inclusive, and Privacy-Enhanced Crowdsourcing Task Matching Based on Blockchain V-PEAKS: Verifiable, Policy-Hiding, and Expressive Attribute-Based Encryption Scheme with Keyword Search Verifiable search results Partially hidden policy (attributes divided into public attribute names and hidden attribute values) Expressive access control and keyword search, represented as conjunctions, disjunctions, or any Boolean formulas with numeric attribute comparison.

Summary Table HS: Hybrid Storage, OD: Outsourced Decryption, PP: Privacy of Policy, PA: Privacy of Attributes, VDI: Verification of Data Integrity, VAP: Verification of Access Permission, PV: Public verification, SA: Sanitization, RE: Revocation, KS: Keyword Search VT: Verification of Transformation by CS Paper HS OD PP PA VDI VAP PV SA RE KS 1 Xiao2022 ✅ ❌ ❌ ❌ ✅ ✅ VAP ❌ ✅ ❌ 2 Zhang2022 ✅ ❌ ✅ ✅ ✅ ✅ VAP ❌ ❌ ❌ 3 Guo2023 ✅ ✅ ❌ ❌ ✅ ❌ ❌ ❌ ✅ ❌ 4 Li2024 ❌(without CS) ✅ ✅ ✅ ✅ ✅ both ❌ ❌ ✅ 5 Jiang2024 ✅ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌ 6 He2022 ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ 7 Yan2023 ❌ ✅ ✅ ❓ ✅ ✅ ✅ ❌ ❌ ✅ 8 Zhao2023 ✅ ✅ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌ 9 Fan2020 ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ ❌ 10 Cui2020 ✅ ✅ ❌ ❌ ✅ ✅ both ❌ ❌ ❌ 11 Yang2023 ✅ ✅ ❌ ❌ ✅ ✅ ❌ ❌ ✅ ❌ 12 Gan2023 ✅ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌ 13 Hou2024 ✅ ✅ ❌ ❌ ✅ ✅ both ❌ ❌ ❌ 14 Jiang2022 ✅ ✅ ❌ ❌ ✅ ❌ ❌ ❌ ✅ ❌ 15 Guo2023 ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ❌ Blockchain Based Multi-Authority Fine-Grained Access Control System With Flexible Revocation Meiyan Xiao , Qiong Huang , Member, IEEE, Ying Miao, Shunpeng Li, and Willy Susilo , Fellow, IEEE; IEEE TRANSACTIONS ON SERVICES COMPUTING (TSC CCF A) 2022 ...

1. Generate crypto material for new peer Modify the script test-network/organizations/fabric-ca/registerEnroll.sh to add the configuration of peer1: infoln "Registering peer1" set -x fabric-ca-client register --caname ca-org1 --id.name peer1 --id.secret peer1pw --id.type peer --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem { set +x; } 2>/dev/null infoln "Generating the peer1 msp" set -x fabric-ca-client enroll -u https://peer1:peer1pw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp --csr.hosts peer1.org1.example.com --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem { set +x; } 2>/dev/null cp ${PWD}/organizations/peerOrganizations/org1.example.com/msp/config.yaml ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/config.yaml infoln "Generating the peer1-tls certificates" set -x fabric-ca-client enroll -u https://peer1:peer1pw@localhost:7054 --caname ca-org1 -M ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls --enrollment.profile tls --csr.hosts peer1.org1.example.com --csr.hosts localhost --tls.certfiles ${PWD}/organizations/fabric-ca/org1/tls-cert.pem { set +x; } 2>/dev/null cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/signcerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/server.crt cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/keystore/* ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/server.key cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/msp/tlscacerts/ca.crt cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/tlscacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem cp ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/cacerts/* ${PWD}/organizations/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem Then, we can see that the MSP files of peer1 are generated in test-network/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp. These files identify the identity of peer1. ...