A RFC de multimédia usa pares de chaves criptográficas ao assinar pedidos. A RFC de multimédia usa um conjunto de chaves para armazenar pares de chaves que são usados ativamente para assinar pedidos. Pode ter até três chaves públicas e três chaves partilhadas de validação, para um total de seis chaves por conjunto de chaves.
Também pode remover chaves não usadas de um conjunto de chaves. A adição e a remoção de uma chave são normalmente denominadas rotação de segredos. A rotação de segredos permite-lhe fazer o seguinte:
- Adicione novos segredos a um conjunto de chaves de forma segura anexando-os ao conjunto de chaves.
- Gere tokens com o segredo correspondente.
Remova segredos antigos após a expiração do token mais antigo possível.
Por exemplo, suponha que define os tokens de curta duração para expirarem após uma hora. Em seguida, removeria o segredo mais antigo usado para os tokens de curta duração depois de os novos pedidos serem apresentados aos utilizadores durante uma ou mais horas.
Antes de remover um segredo não usado, verifique se não é referenciado nem obtido para
assinar pedidos de utilizadores no servidor da sua aplicação. A remoção prematura de um segredo de um conjunto de chaves impede que a RFC de multimédia valide os pedidos associados a esse segredo. Os utilizadores afetados recebem uma resposta HTTP 403
Forbidden.
Para otimizar o desempenho, a fiabilidade e o custo dos acessos simultâneos ao Secret Manager, os seus segredos de chaves de validação partilhados são colocados em cache durante um período máximo de uma hora. O armazenamento em cache de segredos pode resultar no acesso contínuo a tokens após a eliminação de um segredo do Secret Manager durante um período máximo de uma hora.
Como prática recomendada, altere as chaves regularmente.
Limitações conhecidas
A RFC de multimédia rejeita pedidos assinados com as assinaturas simétricas usadas pela RFC na nuvem com uma resposta HTTP 403.
Atualmente, a RFC de multimédia suporta chaves simétricas com pedidos que usam o formato de token e chaves referenciadas pela RFC de multimédia.
As chaves assimétricas têm de ser geradas como pares Ed25519, com uma chave privada de 512 bits (64 bytes) e uma chave pública de 256 bits (32 bytes). A biblioteca Tink suporta a geração de chaves, a assinatura e a validação de assinaturas Ed25519 com C++, Go, Java e Objective-C.
As chaves assimétricas têm de ter as seguintes características:
Estar codificado em base64 com um comprimento de 44 bytes (com preenchimento) ou 43 bytes (sem preenchimento). São aceites formas preenchidas e não preenchidas de base64.
A chave pública tem de estar codificada no formato base64 seguro para URL. A chave privada pode ser codificada no formato base64 padrão.
Ter uma chave privada correspondente.