Jarkko Sakkinen
Posts
4417Following
315Followers
471OpenPGP: 3AB05486C7752FE1
@briankrebs apparently that ceo has yet to find mastodon ;-) social suicide commentary in every other possible social media. he should author a book called "how to f*ck up your life and beyond"
1
0
1
Jarkko Sakkinen
repeated
repeated
BrianKrebs
briankrebs@infosec.exchange
Edited 1 year ago
A 26-year-old Finnish man was sentenced to more than six years in prison today after being convicted of hacking into an online psychotherapy clinic, leaking tens of thousands of patient therapy records, and attempting to extort the clinic and patients.
https://krebsonsecurity.com/2024/04/man-who-mass-extorted-psychotherapy-patients-gets-six-years/
Even though Julius "Zeekill" Kivimaki has a cybercrime rap sheet thicker than a dictionary, he will end up serving roughly half that time, because all that stuff he did before he turned 18 doesn't count toward first-time offender status.
BTW, the CEO of the now-bankrupt psychotherapy practice was prosecuted as well (database credentials "root/root") but received a suspended sentence.
2
2
1
@signalapp in linux. (once we add x509 support for TPM2, probably 6.11) the CPU certificate delivery could be even delivered with a public key coming from TPM (private key non-existent in the machine). So you could hardware-to-hardware pipeline.
0
0
1
Jarkko Sakkinen
jarkko
hmm... https://www.phoronix.com/news/Linux-610-TPM-Encrypt-Integrity. so it is not yet pulled so no need to announce in the current state "unfinished work" (by definition, given that it is not pulled) ;-)
I'll try to get asymmetric keys soon out which cleans this stack up further as a side-effect. If this did not make into 6.10 then I'll just add it on top of that patch set.
I'll try to get asymmetric keys soon out which cleans this stack up further as a side-effect. If this did not make into 6.10 then I'll just add it on top of that patch set.
0
0
0
@signalapp also e.g. signal would benefit in qa if there was emulated infrastructure in place (my previous post). not that well tested except field tested ofc.
0
0
0
@signalapp like for instance: https://signal.org/blog/building-faster-oram/. none of this applies unless proven otherwise for every single running instance of the client. or if you have a belief system applied.
1
0
0
Jarkko Sakkinen
jarkko
The single biggest issue in confidential computing is still. that there is no legit way to deliver cryptographic proof to client/browser inherited from CPU attestation. i.e. a x509 certificate. and so that it is vendor-neutral. not sure if even @signalapp can do this. who cares what you run in the backend if you cannot prove it.
2
0
0
Jarkko Sakkinen
jarkko
this is still somewhat solid reference: https://www.decentriq.com/article/swiss-cheese-to-cheddar-securing-amd-sev-snp-early-boot
0
0
1
Jarkko Sakkinen
jarkko
I wonder if it would make sense to elf stamp kernel images with some sort of. identifier to check where the image is at in the mainline reflecting to the latest of https://docs.kernel.org/process/cve.html. Or maybe this already exist. It would make in the mainline perhaps because then you could detect "too old" when running multiple distributions.
0
0
0
In SGX attestation, which mostly applies also to TDX, you could possibly use e.g. enclave attribute for this defined by the ISA spec (Intel SDM). I mean for the "fake stamp". Attestation can refuse to attest if the provision matches to some list inside archiectural enclave (aka Intell signed) but that "fake stamp" attribute is not set.
1
0
0
because of the hard-bound bare metal depeendency quality assurance in the real sense of that word like super-transparent does not exist in this world for confidential computing no wonder it is confidential when it is not even measured by most of the qa infrastructure existing. totally fights against the marketing promise.
1
0
0
heck maybe it would be even possible to fixup "knowingly known cryptographic material" that would be fixed up also to the qemu code base to which Intel's and AMD's servers would respond as legitimately.or maybe salt somehow to stamp the fake stamp. like just for infrasturcuture QA type of stuff use.
this is not an issue in the CA part as e.g. AMD already today has a rate-limited attestation paradigm. so yeah i think really would make sense for companies to spend money for fixing up this.
this is not an issue in the CA part as e.g. AMD already today has a rate-limited attestation paradigm. so yeah i think really would make sense for companies to spend money for fixing up this.
1
0
0
Jarkko Sakkinen
jarkko
imho at least qemu would need snp and tdx emulation in upstream for like testing patches. i mean most have x86 so even rigged emulation would do the job for trivial patch testing
1
0
0
So apparently (after searching) there is previous work https://patchwork.kernel.org/project/keyrings/cover/20200518172704.29608-1-prestwoj@gmail.com/. So I guess I just use some of it (and make it a separate patch with appropriate credits).
1
0
0
Also a bit unclear what is best bet for authentication but it is a non-concern for RFC.
One possible argument for just authentication value at most would be that LUKS2 already blesses with TPM2 policy and kernel communicates by using null seed derived key. Using policy adds robustness but is it worth of added complexity to have two layers of policy, I really don't know at this point.
One possible argument for just authentication value at most would be that LUKS2 already blesses with TPM2 policy and kernel communicates by using null seed derived key. Using policy adds robustness but is it worth of added complexity to have two layers of policy, I really don't know at this point.
1
0
0