Android 전송 계층은 서버, FCM 백엔드, 클라이언트 기기 간의 전체 연결과 함께 전송 계층 보안 (TLS)을 사용하여 보호됩니다. 이렇게 하면 전송 중인 모든 데이터에 강력한 엔드 투 엔드 암호화가 제공되어 네트워크에서 데이터가 가로채이지 않도록 보호할 수 있습니다.
이 강력한 보안 모델은 대부분의 애플리케이션에 적합합니다.
자세한 내용은 FCM 아키텍처 문서를 참고하세요.
포인트 투 포인트 암호화의 한 가지 제한사항은 발신자와 수신자만 메시지를 해독할 수 있는 전체 경로에 대해 암호화되지 않는다는 것입니다.
이러한 이유로 FCM에서는 채팅 메시지나 인증 거래와 같은 개인 정보 보호에 민감한 커뮤니케이션에 엔드 투 엔드 암호화를 사용할 것을 권장합니다. 엔드 투 엔드 암호화를 최대한 활용하려면 서버 및 앱 코드와 같은 상위 수준에서 구현해야 합니다.
민감한 정보에 엔드 투 엔드 암호화 추가
비공개 메시지나 개인 사용자 인증 정보와 같이 특히 민감한 데이터를 처리하는 애플리케이션의 경우 엔드 투 엔드 암호화 (E2EE)를 사용하여 보호 레이어를 추가할 수 있습니다. 이 프로세스에는 FCM에 전송하기 전에 서버에서 메시지 페이로드를 암호화하고 사용자 기기의 앱 내에서 복호화하는 작업이 포함됩니다. 표준 알림 페이로드는 운영체제에서 처리하며 표시되기 전에 앱에서 복호화할 수 없으므로 FCM 데이터 메시지와 함께 작동합니다.
FCM에서는 엔드 투 엔드 암호화를 위한 기본 제공 솔루션을 제공하지 않습니다.
애플리케이션 내에서 이 보안 계층을 구현할 책임은 사용자에게 있습니다. Capillary 또는 DTLS와 같이 이 용도로 설계된 외부 라이브러리와 프로토콜이 있습니다.
개념 예시
E2EE를 사용할 때 FCMdata 페이로드가 변경되는 방식은 다음과 같습니다.
암호화 전 (표준 페이로드):
{"token":"DEVICE_REGISTRATION_TOKEN","data":{"sender":"user123","message_body":"Your 2FA code is 555-123","timestamp":"1661299200"}}
암호화 후 (E2EE 페이로드):
{"token":"DEVICE_REGISTRATION_TOKEN","data":{"encrypted_payload":"aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA=="}}
엔드 투 엔드 암호화를 올바르게 구현한 경우 클라이언트 애플리케이션만이 암호화된 페이로드를 복호화하여 원래 메시지를 표시할 수 있습니다.
대안: 서버에서 직접 콘텐츠 가져오기
엔드 투 엔드 암호화가 앱에 적합하지 않은 경우 대신 빈 데이터 메시지를 전송할 수 있습니다. 이러한 메시지는 앱이 서버에서 직접 콘텐츠를 가져오도록 하는 신호 역할을 합니다. 즉, 민감한 데이터는 앱과 서버 간에만 전송되며 데이터 전송을 위해 FCM를 우회합니다.
이 방법의 단점은 앱이 데이터를 가져오기 위해 서버에 연결할 때 발생할 수 있는 지연입니다. 앱이 데이터 메시지를 수신하면 백그라운드로 전환되기 전에 알림을 표시하는 데 일반적으로 몇 초밖에 걸리지 않습니다. 서버에서 데이터를 가져오는 작업이 이 기간 내에 완료되지 않을 수 있습니다. 이 데이터 가져오기의 성공 여부는 사용자의 기기 연결과 같은 요소에 따라 달라집니다.
따라서 데이터 가져오기가 너무 오래 걸릴 수 있는 상황에 대비해 사용자 환경 대안을 고려하세요. 예를 들어 '새 메시지가 있습니다'와 같은 일반 알림을 표시한 다음 전체 콘텐츠가 검색되면 업데이트할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["\u003cbr /\u003e\n\nThe **Android Transport Layer** , along with the entire connection between your\nserver, FCM backends, and client devices, is secured using **Transport Layer\nSecurity (TLS)** . This provides strong **point-to-point encryption** for all\ndata while it's in transit, protecting it from being intercepted on the network.\nThis robust security model is suitable for the vast majority of applications.\nYou can find more details in the [FCM Architecture](https://firebase.google.com/docs/cloud-messaging/fcm-architecture)\ndocumentation.\n\nOne of the limitations of point to point encryption is that it's not encrypted\nfor its entire path where only the sender and receiver can decode the message.\nThis is why FCM recommends using end to end encryption for privacy\nsensitive communications like chat messages or authentication transcations. In\norder to get the most from end to end encryption, it must be implemented at a\nhigher level, such as within your servers and app code.\n\nAdd End-to-End Encryption for Sensitive Data\n\nFor applications handling particularly sensitive data, like private messages or\npersonal credentials, you can add an additional layer of protection with\n**end-to-end encryption (E2EE)** . The process involves encrypting the message payload on your server before\nsending it to FCM and decrypting it within your app on the user's device. This works with FCM data messages, as standard notification\npayloads are handled by the operating system and cannot be decrypted by your app\nbefore being displayed.\n\nNote that FCM doesn't provide a built-in solution for end-to-end encryption.\nYou are responsible for implementing this security layer within your\napplication. There are external libraries and protocols designed for this\npurpose, such as\n[Capillary](https://android-developers.googleblog.com/2018/06/project-capillary-end-to-end-encryption.html)\nor [DTLS](https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security).\n\nConceptual Example\n\nHere is how the FCM `data` payload changes when using E2EE.\n\nBefore Encryption (Standard Payload): \n\n {\n \"token\": \"DEVICE_REGISTRATION_TOKEN\",\n \"data\": {\n \"sender\": \"user123\",\n \"message_body\": \"Your 2FA code is 555-123\",\n \"timestamp\": \"1661299200\"\n }\n }\n\nAfter Encryption (E2EE Payload): \n\n {\n \"token\": \"DEVICE_REGISTRATION_TOKEN\",\n \"data\": {\n \"encrypted_payload\": \"aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA==\"\n }\n }\n\nIf you have implemented your e2e encryption correctly, the client application is\nthe only party capable of decrypting encrypted payload to reveal the original\nmessage.\n| **Caution:** When implementing end-to-end encryption, never store your encryption keys directly in your APK or in shared storage. This makes them vulnerable to decompilation or unauthorized access, compromising your entire security model.\n\nAlternative: Fetching Content Directly from Your Server\n\nIf end-to-end encryption isn't suitable for your app, you can instead send empty data\nmessages. These messages act as a signal for the app to\nfetch the content directly from your servers. This means the\nsensitive data is only transported between your app and your servers, bypassing\nFCM for the data transfer.\n\nA drawback of this method is the potential delay caused by the app connecting to\nyour server to retrieve the data. When an app receives a data message, it\ntypically has only a few seconds to display a notification before being\nbackgrounded. Fetching data from your server might not complete within this\nwindow. The success of this data fetch depends on factors like the user's\ndevice connectivity.\n\nTherefore, consider user experience alternatives for situations where the data\nfetch might take too long. For example, you could display a generic notification\nlike \"You have a new message\" and then update it once the full content is\nretrieved."]]
