Difference between revisions of "Bedrock"

From wiki.vg
Jump to: navigation, search
(Notes on auth)
 
Line 31: Line 31:
  
 
WIP...
 
WIP...
 +
 +
== Authentication ==
 +
 +
The bedrock auth flow involves the client sending a signed certificate to the server. The client achieves this by first logging in to Xbox Live and then posting its pubkey to a Mojang API. Mojang returns a certificate chain that signs the client certificate. The client certificate is then used to sign client data such as the player's skin. The server then validates the certificate chain until it sees a known Mojang certficate. Thus, the server does not make any HTTP requests to authenticate players.
 +
 +
 +
=== Client Side ===
 +
 +
Roughly:
 +
 +
1. Obtain a user hash and XSTS token from the Windows Live / Xbox Live APIs.
 +
2. Generate a SECP384R1 keypair
 +
5. Sign your client settings using your private key.
 +
3. POST your public key to ``https://multiplayer.minecraft.net/authentication``
 +
4. Prepend the Mojang certificate to the returned certificate chain (not entirely sure why it isn't there already!)
 +
5. Send the certificate chain and client settings to the server in a "Login" packet
 +
 +
=== Server Side ===
 +
 +
Roughly:
 +
 +
1. Receive certificate chain and client settings from the client in a "Login" packet
 +
2. Walk up the certificate chain and validate, until the Mojang cert is reached.
 +
3. Validate the client settings

Latest revision as of 22:21, 14 October 2019

WIP index page for up-to-date Bedrock documentation


Overview

UDP/IP

Unlike Java edition, Bedrock uses UDP. Quoting wikipedia, key characteristics:

  • Unreliable – When a UDP message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission, or timeout.
  • Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.
  • Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
  • Datagrams – Packets are sent individually and are checked for integrity only if they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent.
  • No congestion control – UDP itself does not avoid congestion. Congestion control measures must be implemented at the application level.
  • Broadcasts – being connectionless, UDP can broadcast - sent packets can be addressed to be receivable by all devices on the subnet.
  • Multicast – a multicast mode of operation is supported whereby a single datagram packet can be automatically routed without duplication to very large numbers of subscribers.

UDP often makes sense for video game. For example, it doesn't matter if an entity position update is dropped, duplicated or delivered out of order, because there will be subsequent postition updates that correct the error. However, certain messages (e.g. chat) still need to be delivered reliably. Video games usually employ some middleware that allows reliability, ordering, etc, to be controlled on a packet-by-packet basis over a UDP transport. RakNet is the middleware used by Bedrock, and is described below.

RakNet

RakNet is middleware that adds a bunch of networking features often needed by video games. RakNet supports reliability and ordering on a packet-by-packet basis, maintains the notion of a connection (including congestion control), and will fragment large packets into multiple datagrams. The RakNet source code is available on github under a BSD license.

Bedrock uses RakNet almost exclusively in reliable+ordered mode, and therefore eliminates all the benefits of using UDP in the first place.

Online and Offline

RakNet "connections" initially start in "offline" mode. All RakNet offline packets contain a magic 16 byte sequence.

WIP...

Authentication

The bedrock auth flow involves the client sending a signed certificate to the server. The client achieves this by first logging in to Xbox Live and then posting its pubkey to a Mojang API. Mojang returns a certificate chain that signs the client certificate. The client certificate is then used to sign client data such as the player's skin. The server then validates the certificate chain until it sees a known Mojang certficate. Thus, the server does not make any HTTP requests to authenticate players.


Client Side

Roughly:

1. Obtain a user hash and XSTS token from the Windows Live / Xbox Live APIs. 2. Generate a SECP384R1 keypair 5. Sign your client settings using your private key. 3. POST your public key to ``https://multiplayer.minecraft.net/authentication`` 4. Prepend the Mojang certificate to the returned certificate chain (not entirely sure why it isn't there already!) 5. Send the certificate chain and client settings to the server in a "Login" packet

Server Side

Roughly:

1. Receive certificate chain and client settings from the client in a "Login" packet 2. Walk up the certificate chain and validate, until the Mojang cert is reached. 3. Validate the client settings