Capacitor-업데이터 현재 code-업데이터가 끝에서 끝까지 code 암호화를 지원합니다. Code 서명은 사용자 장치에서 실행되는 업데이트가 손상되지 않았는지 확인하고 Capacitor-업데이터의 표준 웹 등급 보안보다 추가적인 보호를 제공합니다.
Capacitor-업데이터의 기본 보안
기본적으로 Capgo의 보안 모델은 웹 호스팅 제공자와 유사합니다. Capgo은 업데이트를 저장하고 원래 암호화 HTTPS를 사용하여 현대 암호를 사용하여 업데이트를 제공합니다. 개발자의 컴퓨터에서 업데이트를 게시할 때 항상 HTTPS를 사용합니다.
Capgo의 기본 보안은 SSL Labs의 HTTPS 테스트에서 A+ 점수를 받았습니다. (https://www.ssllabs.com, 2022년 11월)
Capgo는 HTTPS를 사용하여 서버와 사용자 장치 간의 네트워크 연결의 개인 정보와 무결성을 보호하는 데 사용되는 웹 호스팅의 최고급 호스트와 유사합니다. 이 보안 수준은 웹과 Ionic 앱이 Capgo을 사용하는 경우 모두 잘 작동합니다.
클라우드 인프라 공급 chain
다른 점은 Capgo와 대부분의 웹 호스트가 공유하는 것이 Capgo와 다른 웹 호스트가 사용하는 하위 수준 클라우드 인프라에서 작동한다는 점입니다. 이 클라우드 제공자와 Capgo 또는 다른 웹 호스트가 운영하는 하드웨어 및 소프트웨어는 클라우드 공급_chain에 포함됩니다.
클라우드 공급_chain과 그 보안 모델은 수많은 웹사이트와 앱에 작동합니다. 클라우드 제공자를 사용하는 모든 웹 개발자는 제공자에 신뢰를 두고 업로드한 파일이 실행되거나 제공되는 파일이 변조되지 않은 파일인지 기대합니다. 클라우드 제공자는 인프라를 안전하게 유지하기 위해 노력합니다.
하지만 명백히, 하드웨어 및 소프트웨어 취약점이 발견됩니다. 클라우드 제공자는 정기적인 일정에 취약점을 패치하고, 악성 소프트웨어를 예방하고(Google의 SLSA), 깊은 방어 계층을 구축하고, 실제로 클라우드 인프라가 대부분의 웹사이트와 앱의 보안 요구 사항을 충족하는 것으로 나타났습니다. 그러나 일부 Ionic 앱은 위험 모델에 취약한 클라우드 인프라를 포함합니다. 이러한 __CAPGO_KEEP_0__ JS 앱에 가장 높은 보안 요구 사항이 있는 웹 위의 앱을위한 우리는 __CAPGO_KEEP_1__와 __CAPGO_KEEP_2__에 __CAPGO_KEEP_0__를 사용하여 끝에서 끝으로 __CAPGO_KEEP_1__를 구축했습니다. __CAPGO_KEEP_0__ Updates 표준 프로토콜), and build layers of defense in depth, and in practice, cloud infrastructure has shown to meet most websites and apps’ security needs. However, some Ionic apps include compromised cloud infrastructure in their threat models. For these Capacitor JS apps with the highest security requirements above the web, we built end-to-end code signing in to Capgo and the Capgo의 끝에서 끝으로 __CAPGO_KEEP_1__를 사용하는 것은 공개 키 암호화 방식을 사용하여 __CAPGO_KEEP_2__ 앱 개발자가 제공하는 원본 업데이트만 실행하는 Capgo의 장치가 사용자에게만 제공되도록 보장합니다..
End-to-end code signing with Capgo
Capgo’s end-to-end code signing uses public-key cryptography to ensure end users’ devices run only unmodified, original updates from the Capacitor app developer.
“Code”은 개발자가 업데이트를 게시한 시점부터 사용자가 장치에 업데이트를 다운로드 및 실행한 시점까지의 모든 흐름을 보호하는 보안을 의미합니다. “Code signing”은 암호화와 개발자의 비밀 개인 키를 사용하여 “code”을 “서명”하고, 나중에 신뢰할 수 있는 공개 키를 사용하여 서명 여부를 확인하는 것입니다.
이것이 어떻게 작동하는지 설명하는 간단한* 스키마입니다.
- 실제로는 복잡하지만 암호화는 어렵습니다
정의:
- AES: Advanced Encryption Standard, 암호화 알고리즘, 암호화와 복호화에 하나의 키를 사용합니다.
- RSA: Rivest–Shamir–Adleman, 비대칭 암호화 알고리즘, 공개 키와 개인 키를 사용합니다.
- 암호화된 데이터.
- 업데이트를 암호화하는 데 사용되는 세션 키.
- 파일에 대한 체크섬.
- 서명: 체크섬이 개인 RSA 키로 암호화된 체크섬입니다. 공개 RSA 키를 사용하여 확인할 수 있습니다.
업데이트를 암호화하는 데 AES 알고리즘을 사용합니다. 업로드를 위해 매번 랜덤한 AES 키를 생성하고, AES 키와 체크섬(이하 “서명”)을 개발자의 개인 RSA 키로 암호화합니다. 개발자의 공개 RSA 키를 사용하여 앱에서 AES 키와 서명(체크섬으로 변환)을 복호화하고, 나중에 복호화된 AES 키를 사용하여 업데이트를 복호화하고, 복호화된 업데이트의 체크섬을 계산하고, 복호화된 서명과 비교합니다.
We use two different encryption algorithms because RSA cannot be used to encrypt large amounts of data. AES is used to encrypt the update and RSA is used to encrypt the AES key and the checksum.
With this, even Capgo cannot read the content of your bundle. This is a robust security model that is used by many enterprise customers.
Update encryption V2 2024-08-27:
- We switched the key type that is stored in the app. This was done in order to prevent inferring the public key (previously used for encryption) from the private key (previously used for decryption). Now, the app stores the public key (now used for decryption).
- We switched the checksum from the CRC32 algorithm to the SHA256 algorithm. We also started signing the bundle. When encryption V2 is configured, an update must have a valid signature. This is strictly enforced by the plugin. We now enforce a valid signature encryption V2 is configured. These 3 changes have been done after a security analysis from a community member. They are here to prevent cryptographic attacks during update.If you used encryption V1, migrate to V2 to benefit from the new security features. Follow the migration instructions.
- With end-to-end __CAPGO_KEEP_0__ signing, __CAPGO_KEEP_1__ becomes a “trustless” cloud infrastructure. If one of __CAPGO_KEEP_2__’s cloud providers or even __CAPGO_KEEP_3__ itself were to modify a __CAPGO_KEEP_4__-signed update, end users’ devices would reject that update and run the previous, trusted update that’s already on the device.
__CAPGO_KEEP_0__는 업데이트의 내용을 읽을 수 없습니다. 많은 기업 고객이 사용하는 강력한 보안 모델입니다. __CAPGO_KEEP_0__는 업데이트의 내용을 읽을 수 없습니다. 많은 기업 고객이 사용하는 강력한 보안 모델입니다..
With end-to-end code signing, Capgo becomes a “trustless” cloud infrastructure. If one of Capgo’s cloud providers or even Capgo itself were to modify a code-signed update, end users’ devices would reject that update and run the previous, trusted update that’s already on the device.
While web-level HTTPS is sufficient for many apps, some large companies find the extra level of security from end-to-end code signing appealing. Some of these companies make finance apps that issue high-value, permanent transactions. Other companies have CISOs who include compromised cloud infrastructure in their threat models. We built end-to-end code signing in to Capgo for these use cases and are interested in hearing more from companies with higher-level security needs.
기업 고객을 위한 시작
보안에 매우 관심이 있는 대형 회사 또는 프로젝트를 위한 code signing을 쉽게 설정하고 유지할 수 있도록 하기 위해, 우리는 다음과 같은 기능을 제공합니다.
- 빠른 인증서 설정 및 구성
- code signing 개발 서버를 위한 Capgo 및 개발 빌드의 지원
- 업데이트마다 code signing
Capgo code signing은 모든 고객에게 사용 가능합니다. 시작하기 위해서는 설정 지침.
크레딧
__CAPGO_KEEP_0__ signing을 위한 많은 도움을 주신 Ionic이 문서는 이에 기반합니다. 이 기사 Chat-GPT-3와 함께 재작성 및 적응되었습니다.
Capacitor 업데이터를 위한 E2E 암호화의 Code 서명에서 계속하세요.
__CAPGO_KEEP_0__ 업데이터를 위한 E2E 암호화의 __CAPGO_KEEP_1__ 서명으로 보시면 E2E Encryption for Capacitor Updater via Code Signing __CAPGO_KEEP_2__와 연결하세요. __CAPGO_KEEP_2__ __CAPGO_KEEP_2__의 구현 세부 사항에 대해 설명합니다. __CAPGO_KEEP_3__ __CAPGO_KEEP_3__의 구현 세부 사항에 대해 설명합니다. Capgo 보안 스캐너 Capgo 보안 스캐너의 제품 워크플로에 대해 설명합니다. Capgo 보안 Capgo 제품 워크플로우에서 보안을 위해 Capgo 신뢰 센터 Capgo 제품 워크플로우에서 신뢰 센터를 위해
