翻訳待ち：Darkbloom (decentralized AI inference on Macs)-community security audit findings

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Summary Darkbloom makes strong privacy and security claims -- \"plaintext exposure occurs only within hardware-encrypted memory,\" per-request NaCl Box encryption, Secure Enclave attestation chains, and a threat model explicitly compared to Apple Private Cloud Compute. These are serious claims that deserve serious verification. This issue is a constructive request for Eigen Labs to commission and publish the results of an independent, named third-party security audit of the Darkbloom system (coordinator, provider binary, enrollment flow, and attestation protocol). This is not a criticism of the engineering work done so far -- it is a request for the kind of transparency that the project's own security posture demands. ## Specific Technical Concerns ### 1. Attestation: self-asserted serial residual (your own issue #328) Issue #328 (\"MDA gate: Apple-root the device serial to the connection's SE key\") documents a known gap where provider-supplied device serials are not cryptographically bound to the Secure Enclave key used in the connection. The issue describes a concrete spoofing scenario: > A malicious actor with two enrolled Macs -- one genuinely SIP-enabled (M_clean) and one with protections disabled (M_dirty) -- could register M_dirty with its own SE key but claim M_clean's serial. MDM lookup validates the claimed serial as SIP-on. The nonce flows through the clean device, returning a valid Apple-signed cert. The gate approves routing despite M_dirty operating without security features. The issue itself notes this cannot be fully resolved until macOS 27 provides the necessary platform primitives. This means the attestation chain -- a foundational security claim -- has a known, documented, unfixed gap in production today. An independent auditor should evaluate the actual risk surface and whether the documented compensating controls (MDM enrollment, SIP-on checks, live SE challenges) are sufficient. ### 2. Coordinator plaintext access The project documentation states that the coordinator running in a GCP Confidential VM handles routing, billing, and attestation, and that \"plaintext exposure occurs only within hardware-encrypted memory -- it's never logged or retained.\" This is an important claim, but it is ultimately a claim made by the operator about the operator's own infrastructure. Consumers have no independent way to verify that: - The Confidential VM configuration is correctly deployed and maintained - No logging, telemetry, or debugging code captures plaintext in transit - Access controls on the GCP project prevent Eigen Labs employees from attaching debuggers or extracting memory snapshots from the Confidential VM - The coordinator binary running in the Confidential VM matches any auditable source This is precisely the class of claim that a third-party audit exists to verify. ### 3. Un-notarized binary distribution The Darkbloom provider binary (darkbloom CLI) is distributed to macOS users for execution with elevated privileges (Secure Enclave access, MDM enrollment, kernel-level PT_DENY_ATTACH). If this binary is not notarized by Apple, users must override Gatekeeper to run it. This means: - Apple's automated malware scan has not been applied - The binary is not stapled with a notarization ticket that macOS can verify offline - Users are trained to bypass a security warning, which undermines the very security culture the project depends on An auditor should verify the binary supply chain: reproducible builds, code-signing identity, notarization status, and whether the distributed binary matches the open-source repository. ### 4. MDM enrollment scope and exclusivity Issue #691 documents that Darkbloom's MDM enrollment displaces any existing MDM profile, because macOS permits only one MDM enrollment per device. This has significant implications: - Users with employer- or university-managed devices cannot participate without removing institutional security controls - Users who enroll grant Darkbloom's MDM server the ability to query device security posture (SIP status, Secure Boot level, FileVault status, OS version) - The scope of the MDM profile -- what commands it can issue, what data it collects, and what server-side retention policies apply -- has not been publicly documented or independently verified An independent audit should evaluate exactly what the MDM profile can and cannot do, whether its scope is minimal, and what data flows to the coordinator as a result. ### 5. Provider binary hardening claims The project claims the provider process uses PT_DENY_ATTACH to prevent debugger attachment and runs inference in-process with \"no subprocess, local server, or IPC to tap.\" These are strong claims. An auditor should verify: - Whether PT_DENY_ATTACH is correctly applied and cannot be trivially bypassed (e.g., by a provider operator with root access loading a kernel extension) - Whether the in-process inference claim holds -- that no temporary files, swap pages, or crash logs could leak plaintext - Whether the NaCl Box key exchange is correctly implemented and whether forward secrecy is achieved ## Questions for Eigen Labs 1. Has any independent security audit been conducted? If so, by whom, and will the results be published? 2. Is the provider binary Apple-notarized? If not, what is the timeline for notarization? 3. What is the exact scope of the MDM profile? Can you publish the MDM enrollment profile XML and the set of commands/queries it issues? 4. What is the attestation gap closure plan? Issue #328 notes the full fix requires macOS 27. What compensating controls are in place today, and have they been independently validated? 5. Can consumers verify the coordinator binary? Is the coordinator built reproducibly from this repository? Is there a mechanism for consumers to verify what is actually running in the Confidential VM? 6. What data does the coordinator retain? Beyond the claim that plaintext is \"never logged or retained,\" can you publish data-flow diagrams showing exactly what is stored, for how long, and who has access? ## Precedent Independent security audits are standard practice for infrastructure-layer projects in this ecosystem: - EigenLayer (Eigen Labs' own restaking protocol) has published audits by Trail of Bits, Sigma Prime, and others before mainnet launch - Apple Private Cloud Compute -- the system Darkbloom explicitly compares itself to -- published a detailed security architecture paper, invited independent security researchers, and established a bug bounty program before launch - Ollama, vLLM, and other open-source inference frameworks have undergone or are undergoing security reviews as they move toward production use - WireGuard published a formal verification of its protocol and multiple independent audits before recommending production use Darkbloom asks users to install a closed-source binary, enroll their hardware in an MDM profile, grant Secure Enclave access, and route potentially sensitive inference requests through Eigen Labs infrastructure. The security bar for this level of trust should match or exceed the precedents above. ## Requested Actions 1. Commission a security audit from a named, reputable firm (e.g., Trail of Bits, NCC Group, Cure53, or similar) 2. Scope the audit to cover: coordinator infrastructure, provider binary, MDM profile, attestation protocol, key exchange, and data retention 3. Publish the full audit report (not a summary) on this repository or a linked page 4. Establish a bug bounty program for ongoing security research 5. Publish the MDM enrollment profile and coordinator data-flow documentation ## Tone Note This issue is filed in good faith. The Darkbloom architecture is ambitious and the engineering is clearly thoughtful -- the existence of issues like #328 (self-documenting a known attestation gap with a detailed threat analysis) demonstrates genuine security awareness. The request here is simply that the project's security claims be independently verified before users are asked to trust them with sensitive data and hardware access. That is a reasonable standard for any production security-critical system.