홈으로 돌아가기

MAX 위의 암호화: Android/iOS용 AES-256

이 기사는 AES-256-GCM과 PBKDF2를 사용한 메신저 위의 암호화를 위한 오프라인 Dark Message 애플리케이션 개발을 설명합니다. 크로스플랫폼 UTF-8 문제 분석, Mac 없이 GitHub Actions CI/CD, App Store 배포. 완전한 Android-iOS-Windows 호환성.

모든 메신저를 위한 오프라인 AES-256 암호화
Advertisement 728x90

메신저를 통한 크로스 플랫폼 암호화: iOS와 Android 구현

엔드투엔드 암호화가 없는 허용된 메신저만 사용 가능한 상황에서는 기존 전송 수단 위에 보호 계층이 필요합니다. Dark Message는 AES-256-GCM을 사용하여 메시지, 파일, 문서를 오프라인에서 암호화합니다. 암호화된 콘텐츠는 발신자나 수신자의 기기에 원본 데이터에 접근하지 않고도 MAX, 이메일, SMS 등 어떤 전송 채널로도 복사할 수 있습니다.

이 앱은 네트워크 권한 없이 작동하며 데이터를 로컬에서 암호화합니다. 수신자는 공유 비밀번호를 사용해 복호화하여 Android, iOS, Windows 간 호환성을 보장합니다.

아키텍처와 암호화

대칭 암호화는 기밀성과 인증을 위해 AES-256-GCM을 기반으로 합니다. 키 유도는 무작위 솔트와 함께 600,000회 반복하는 PBKDF2-HMAC-SHA512를 사용합니다. 암호화된 패킷 형식은 다음과 같습니다: [버전:1B][콘텐츠 유형:1B][솔트:16B][논스:12B][암호문+GCM_태그:NB]. 이는 동일한 비밀번호와 입력 데이터에 대해서도 고유한 암호문을 보장합니다.

Google AdInline article slot

지원 유형:

  • 텍스트 메시지 (Base64 문자열로 출력).
  • 이미지와 파일 (.darkm으로 출력).
  • 모든 형식의 문서 (PDF, DOCX, XLSX, ZIP).

AI를 활용한 개발: 아키텍처부터 디버깅까지

Claude는 코드 생성, 구조 설계, 오류 분석에 사용되었습니다. AI는 아키텍처를 제안하고 초안을 작성하며 크로스 플랫폼 테스트 중 바이트 비교를 지원했습니다. 최종 테스트와 개선은 실제 기기에서 수동으로 수행되었습니다.

과정:

Google AdInline article slot
  • 작업 설명—구조 제안.
  • 코드 생성—로컬 테스트.
  • 불일치 디버깅 (바이트, 키).
  • 검증을 위한 Python 테스트.

AI는 크로스 플랫폼 팀을 대체하며 개발을 가속화했지만, 하드웨어 검증의 필요성을 없애지는 못했습니다.

Mac 없이 CI/CD: iOS용 GitHub Actions

iOS 빌드는 GitHub Actions의 가상 macOS에서 진행됩니다. 파이프라인은 YAML에서 프로젝트를 생성하기 위해 XcodeGen을 사용하여 저장소에 .xcodeproj를 저장하지 않습니다. 자동 서명 및 App Store Connect 업로드.

파이프라인 단계:

Google AdInline article slot
  • 저장소 복제.
  • Xcode 프로젝트 생성.
  • 빌드 및 아카이브.
  • TestFlight 업로드 (커밋 후 15분).

Android는 Gradle(APK/AAB)을 통해 로컬에서 빌드됩니다. 이를 통해 Windows에서 크로스 플랫폼 개발이 가능합니다.

크로스 플랫폼 문제와 해결책

플랫폼 간 동일한 복호화를 보장하는 과정에서 키 불일치가 발견되었습니다.

키 유도에서의 UTF-8

Java PBEKeySpec은 비밀번호를 char[]로 변환하는 반면, iOS는 UTF-8 바이트를 사용합니다. 해결책: Android에서 passphrase.toByteArray(Charsets.UTF_8)를 사용한 맞춤형 PBKDF2.

시각적으로 동일한 문자

비밀번호 "a" (키릴 문자 U+D0B0)를 iPhone에서 사용할 때와 Android에서 라틴 문자 "a" (U+0061)를 사용할 때의 차이. Python 스크립트 테스트로 키 차이를 확인했습니다.

KDF 선택

Android의 Argon2id는 CI/CD와 충돌했습니다(의존성 문제). PBKDF2로 전환하여 통일성을 확보했습니다.

출시: App Store와 RuStore에서 얻은 교훈

App Store: 메타데이터에 메신저 언급, 생성된 스크린샷, 불완전한 현지화로 인해 두 번 거절되었습니다. 요구사항: 실제 스크린샷, 깔끔한 설명, 완전한 현지화, 연락처가 포함된 지원 URL.

RuStore: 스크린샷은 엄격히 9:16 비율, versionCode 증가.

핵심 포인트

  • 오프라인 작동: 네트워크 요청 없음, 데이터가 기기를 떠나지 않음.
  • 호환성: Android에서 암호화—iOS/Windows에서 복호화.
  • 견고성: 무차별 대입 공격에 대비한 AES-256-GCM + PBKDF2 (60만 회 반복).
  • 단순성: 어떤 전송 수단을 통해서도 복사/붙여넣기.
  • 개방성: 감사를 위한 오픈 소스 가능성.

프로젝트에서의 활용

기존 앱에 통합하려면 암호화 로직을 내보내면 됩니다. 중급/시니어 개발자에게: 크로스 플랫폼 호환성을 위해 고정된 매개변수로 PBKDF2를 구현하세요. 실제 기기에서 테스트하며 UTF-8 비밀번호 정규화에 집중하세요.

— Editorial Team

Advertisement 728x90

다음 읽기