Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure Memory Erasing for SPIKE Nexus and SPIKE Keeper #68

Open
v0lkan opened this issue Dec 31, 2024 · 2 comments
Open

Secure Memory Erasing for SPIKE Nexus and SPIKE Keeper #68

v0lkan opened this issue Dec 31, 2024 · 2 comments
Labels

Comments

@v0lkan
Copy link
Contributor

v0lkan commented Dec 31, 2024

Both SPIKE Nexus and SPIKE keeper (albeit temporarily) store root keys and Shamir Shards that they don't directly need.

Although these are deleted when no longer needed, it is up to Go garbage collector "when" to delete them.

Instead, we need to zero out unused data before gc.

According to NIST SP 800-88 Rev. 1 (Guidelines for Media Sanitization), a single overwrite pass with zeros is sufficient for modern storage devices. And since our data is in memory, one pass should be enough too. Multiple pass overwrites (like Gutmann's 35-pass method) are no longer considered necessary (due to high storage densities in modern devices).

The key is ensuring the overwrite actually occurs and isn't optimized away by the compiler, which the previous code handles correctly.

Here is one way to do it:

func Clear[T any](s *T) {
    p := unsafe.Pointer(s)
    size := unsafe.Sizeof(*s)
    b := (*[1 << 30]byte)(p)[:size:size]
    runtime.KeepAlive(s) // make sure the data is actually wiped before gc has time to interfere.
    for i := range b {
        b[i] = 0
    }
}

// Usage
type SensitiveData struct {
    Key    [32]byte
    Token  string
    UserId int64
}

func main() {
    data := &SensitiveData{...}
    defer Clear(data)
    // Use data
}
@v0lkan v0lkan added good first issue Good for newcomers security labels Dec 31, 2024
@kfox1111
Copy link

It would be interesting to try and chat with some of the folks under the cncf that are involved with confidential computing... Maybe there is an existing, nice interface we could reuse that keeps the keys in protected memory, and/or has nice wiping features.

@v0lkan
Copy link
Contributor Author

v0lkan commented Jan 4, 2025

It would be interesting to try and chat with some of the folks under the cncf

That's a good idea indeed; I'm noting it down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants