I have my 128GB MicroSD patiently waiting to be fully inserted into my Switch when ready.
A question regarding nintendos signing key which was talked about a few pages back:
If they sign the FW, the switch must have a matching key to check the validity.
Do we have write access to that key via RCM?
If yes, couldn't we extract it, replace it with a key of our own and sign CFW with the private key to that key.
The old key could then be used by the CFW for further operation.
If they sign the FW, the switch must have a matching key to check the validity.
Do we have write access to that key via RCM?
If yes, couldn't we extract it, replace it with a key of our own and sign CFW with the private key to that key.
The old key could then be used by the CFW for further operation.
The public key is different from the private and you cannot obtain one from another (https://en.wikipedia.org/wiki/Public-key_cryptography)
I'm aware of that.
My suggestion is:
Creating a new public/private key pair
Writing the new public key to the Switch while backing up the original public key
Using the newly created private key to sign the CFW and give the CFW the original public key for further use
My suggestion is:
Creating a new public/private key pair
Writing the new public key to the Switch while backing up the original public key
Using the newly created private key to sign the CFW and give the CFW the original public key for further use
That's not how cryptography works... at all. Although there is a public and private key, for each certificate there is also a public and private Root certificate, meaning the start of the certificate chain. These are both stored on Nintendo's servers and typically not shared at all other than with their subordinate root certificate servers, which are the servers that create the aforementioned public and private certificates used on end devices. If we could validate against Nintendo's certificate with our own keys then they would serve no purpose whatsoever.
The example I cite is just a typical certificate PKI deployment. I have no idea what Nintendo's PKI looks like.
I just thought that, assuming we have write access to the required areas, we could overwrite the key Nintendo uses while booting, since they still have to be stored on the console.
So, if you could overwrite all keys with keys of your own, it wouldn't matter if you didn't have Nintendos Rootcertificate, or rather the private key to that certificate, since you would be implementing a whole new certificate chain.
The original keys could then be used further down to decrypt files which are encrypted with Nintendos Rootkey.
My guess would also be, that if if were that easy, it would be done that way, but I'd still be interested, why exactly that wouldn't work.
It won't work because the keys used on endpoints (our console) is signed by the servers that issued them. The root certificate is signed by the root server only and given access to the subordinate server and then the root server is shut off, never to turn on again until the root is about to expire. This is how key/certificate validation is obtained. If any certificates are spoofed, the servers would know they are invalid because they weren't signed by the subordinate server - All certificates are stored on the subordinate server when issued, so if a certificate is presented that it doesn't know about, then the request is denied. All subordinate certificates are signed by the root, which if spoofed won't have the proper hash (usually 2048 but 4096 bit keys offer better encryption) or matching server name of the root server that originally issued it.
Again, this is a very high level explanation of how PKI works, but I manage one for my office and in general that's how our identity servers know which endpoints to trust or not trust.
But for a server to validate the keys, the switch first has to connect to the server. Afaik this doesn't happen during the boot sequence. So all certificates, keys or, if you will, (local) certificate servers are under our control.
So basically you could completely implement your own crypto infrastructure complete with rootkey, intermediate and endpoint certificates, chain of trust, etc...
This would obviously not work as soon as you tried to contact Nintendos server exactly because of the reasons you just wrote, but only for the boot process or maybe only until the CFW is loaded and starts to load the original firmware, you would be in complete control of all keys and certificates.
As soon as you require access to Nintendos servers, code signed by them or similar things, you would fall back to the original certificates which are signed by Nintendo.
This approach would just simplyfy the boot procedure and would, possibly, allow to coldboot CFW, which then loads the original firmware, if, and only if, we have write access to all the places on the console where certificates, keys etc... are stored.
So my question was, if we have access to all the necessary places on the switch and if yes, what other problems would be there that would prohibit this approach.
Again: In this scenario we would be in control of all locations on the console where certs/keys are stored and, in return, of every asymmetrical signing, validating, en- and decrypting step in (and only in) the boot chain.
I see your approach now. TBH I don't know enough about Horizon. I would assume certificates in the Switch's scenario are only used for online access and have nothing to do with booting the console. The issue with coldboot hax is that there isn't an exploit available yet to enable TZ execution before Horizon loads. FG is used before Horizon even starts loading which allows us to gain access, but for Horizon above 1.0.0 there are no exploits available that load Horizon and allow immediate TZ access yet. It's been stated it is possible on firmware up to 3.0.0, but will take quite a bit of time from the devs to find them.
Last edited by Maximilious,
Ah, thank you. That was the answer I was waiting for
I just came up with that idea, because someone said some pages ago, that the main reason, we could noch just swap Nintendos FW with our own is, that Nintendo signes (or encrypts?) their firmware with their key, so that we would run intoproblems if
we tried booting a non signed (encrypted?) rom.
So I guess some kind of key has to be on the console, so that nintendo can check the rom against that (decrypt the rom with?)
According to switchbrew (search for "BCT", as I can't post links yet), the first key to start up the crypto infrastructure of the Switch seems to be at 0x450 in the BCT, which is flagged as writable and gets in fact overwriten by Nintendo during (major?) Systemupdates.
As far as I understand from switchbrew(search for "cryptosystem" this time), the bootrom then uses that infromation and a console specific key to kickstart some other crypto processes until finally the system rom gets booted.
I guess I just answered my own question while writing this. It seems that part of the cryptochain uses a console specific key generated by the Tegra which seems to be unaccessible to us.
From Switchbrew:
The falcon processor (TSEC) generates a special console-unique key (that will be referred to as the "tsec key").
This is presumably using data stored in fuses that only microcode authenticated by NVidia has access to.
So to circumvent that at this point, you'd have to essentially write your own bootloader and trustzone to run the Switch's systemrom in, which, as far as I understand, is exactly what Atmosphere is doing...
Ok, was just a simple idea that popped up in my head after reading of the issue with the signed rom
Ah, thank you. That was the answer I was waiting for
I just came up with that idea, because someone said some pages ago, that the main reason, we could noch just swap Nintendos FW with our own is, that Nintendo signes (or encrypts?) their firmware with their key, so that we would run intoproblems if
we tried booting a non signed (encrypted?) rom.
So I guess some kind of key has to be on the console, so that nintendo can check the rom against that (decrypt the rom with?)
According to switchbrew (search for "BCT", as I can't post links yet), the first key to start up the crypto infrastructure of the Switch seems to be at 0x450 in the BCT, which is flagged as writable and gets in fact overwriten by Nintendo during (major?) Systemupdates.
As far as I understand from switchbrew(search for "cryptosystem" this time), the bootrom then uses that infromation and a console specific key to kickstart some other crypto processes until finally the system rom gets booted.
I guess I just answered my own question while writing this. It seems that part of the cryptochain uses a console specific key generated by the Tegra which seems to be unaccessible to us.
From Switchbrew:
The falcon processor (TSEC) generates a special console-unique key (that will be referred to as the "tsec key").
This is presumably using data stored in fuses that only microcode authenticated by NVidia has access to.
So to circumvent that at this point, you'd have to essentially write your own bootloader and trustzone to run the Switch's systemrom in, which, as far as I understand, is exactly what Atmosphere is doing...
Ok, was just a simple idea that popped up in my head after reading of the issue with the signed rom
I think the public key is stored within the on-SoC ROM so changing it is not really feasible. (I'm not sure if anyone has ever managed to swap out the rom.) You could maybe swap out the CPU entirely for one without secure boot enabled (We have all the keys we need, but that might just be wishful thinking)
http://infocenter.arm.com/help/topi...ENC-009492C_trustzone_security_whitepaper.pdf (See the secure boot section)
Does anyone know why the commit count on atmosphere is going down? This is no criticism I am very thankful for what all the Devs do and I don't wanna rush it. I was just interested if anyone knows if there is a specific reason
Does anyone know why the commit count on atmosphere is going down? This is no criticism I am very thankful for what all the Devs do and I don't wanna rush it. I was just interested if anyone knows if there is a specific reason
Lack of interest, lack of time, maybe most of the work is done, or devs are taking a break to relax and free their mind. They are doing it on their free time and for free, a curve like that it's to be expected.
They might have almost everything ready and could be waiting for TX release to drop the bomb...
Like yeah we are dead and then KABOOM Nuclear bomb released out of a sudden in the middle of the silence.
Like yeah we are dead and then KABOOM Nuclear bomb released out of a sudden in the middle of the silence
.
Maybe that was the easy but bulky part of the code? and now they are whit the smaller but more difficult parts of the code?Does anyone know why the commit count on atmosphere is going down? This is no criticism I am very thankful for what all the Devs do and I don't wanna rush it. I was just interested if anyone knows if there is a specific reason
There was a hiccup last week because Scires was sick/busy with other stuff, such as dataming Pokemon Quest.
Similar threads
-
- Portal
-
- Portal
-
- Portal
-
- Portal
