Open yeahaluu opened 2 years ago
개인적으로는 공수가 들더라도 "우리 앱은 암호화되었으니까 편하게 사용하시면되요!" 라는 말을 하기 위해서는 해당 작업이 필요하다고 생각합니다. 하지만 말씀해주신대로 앱의 필수 기능들에 비해서 우선순위가 상대적으로 떨어지기 떄문에, 테스트플라이트를 올린 후 테스트플라이트 업데이트를 통해 금요일 전까지 해보는 방향으로 가면 좋지 않을까 싶습니다!
개인적으로는 공수가 들더라도 "우리 앱은 암호화되었으니까 편하게 사용하시면되요!" 라는 말을 하기 위해서는 해당 작업이 필요하다고 생각합니다. 하지만 말씀해주신대로 앱의 필수 기능들에 비해서 우선순위가 상대적으로 떨어지기 떄문에, 테스트플라이트를 올린 후 테스트플라이트 업데이트를 통해 금요일 전까지 해보는 방향으로 가면 좋지 않을까 싶습니다!
좋은 의견 감사합니다! 해당 작업이 필요한 것에도 동의하여 테스트플라이트를 올린 후 업데이트 해보는 것 너무 좋은 방법 같습니다👍
쉐리님이 정리를 정말 잘해주셔서 데이터 암호화의 원리에 대해서 빠르게 이해 할 수 있었습니다! 🤩 의문점이 몇가지 있는데, 저희 서비스에서 user1의 장치란 note를 작성하는 웹을 의미할까요? 그리고 firestore가 예시로 들어져 있는데, 저희 realtimeDB를 그대로 사용해도 될까요?
아 그리고 해당 AES 방식을 종단간암호화방식으로 이해해도 될까요?? 텔레그램에서 사용하는 방식이 떠올라서 갑자기 궁금해졌습니다ㅋㅋ
쉐리님이 정리를 정말 잘해주셔서 데이터 암호화의 원리에 대해서 빠르게 이해 할 수 있었습니다! 🤩 의문점이 몇가지 있는데, 저희 서비스에서 user1의 장치란 note를 작성하는 웹을 의미할까요? 그리고 firestore가 예시로 들어져 있는데, 저희 realtimeDB를 그대로 사용해도 될까요?
첫번째 질문에 대해 먼저 말씀 드리면, user1이 note
를 암호화하여 작성하는 웹, user2가 note
를 받아서 복호화(암호 해독)하는 앱입니다.
두번째 질문에서, firestore로 적었는데 오타입니다🥲 다른 분들의 이해를 위해 firebase로 바꿔놓겠습니다. AES방식은 서버에서 암호화하는 것이 아닌, 클라이언트에서 암호화하는 것이기 때문에 realtime DB와 firesotre에 큰 차이는 없습니다.😊
놔스닥이 말씀해주신대로 우선 기존 스프린트를 우선적으로 진행하고 테스트 플라이트가 나온 뒤에 목요일 오전 쯤 작업을 해서 테스트 플라이트를 업데이트 하는 것이 나을 것 같습니다. 혹시나 암호화 작업을 할 시간이 부족하다면 화면이나 모니터로 암호화가 안된다는 것을 명시하는 방향으로 하면 될 것 같습니다. 댓글로 user1, user2 설명 감사합니다! 설명을 잘해주셔서 너무 쉽게 이해가 됐습니다! 👍
놔스닥이 말씀해주신대로 우선 기존 스프린트를 우선적으로 진행하고 테스트 플라이트가 나온 뒤에 목요일 오전 쯤 작업을 해서 테스트 플라이트를 업데이트 하는 것이 나을 것 같습니다. 혹시나 암호화 작업을 할 시간이 부족하다면 화면이나 모니터로 암호화가 안된다는 것을 명시하는 방향으로 하면 될 것 같습니다. 댓글로 user1, user2 설명 감사합니다! 설명을 잘해주셔서 너무 쉽게 이해가 됐습니다! 👍
테스트 플라이트 이후 작업하고, 힘들 경우 명시하는 방향으로 가는 것 너무 좋습니다! 좋은 의견 감사합니다😊👍
아 그리고 해당 AES 방식을 종단간암호화방식으로 이해해도 될까요?? 텔레그램에서 사용하는 방식이 떠올라서 갑자기 궁금해졌습니다ㅋㅋ
찾아보니 AES를 종단감 암호화 방식으로 이해하면 안된다고 합니다! 사실 저도 같은 것이라고 생각하여 찾아보았는데 AES는 암호화 알고리즘일 뿐이라고 합니다!!🌪💥⚡️😱 종단간 암호화가 E2EE(End-to-End Encryption)으로 클라이언트 간 암호화 통신을 뜻하여 AES가 종단감 암호화라고 이해했습니다. 하지만 AES는 암호화알고리즘이기 때문에 종단 간 통신 프로토콜을 구현하는 데 사용할 수 있지만 다른 알고리즘도 사용할 수 있다고 합니다.
이에 대한 자세한 내용은 https://www.quora.com/Is-256-bit-AES-encryption-a-type-of-end-to-end-encryption 여기서 자세히 논의되고 있으니 더 궁금하면 보시는 것을 추천드립니다!
덕분에 AES에 대해 더 자세히 알 수 있었습니다. 감사합니다!!😊👍✨🍊
Contents
TF단계에서 아카데미 할로윈 축제를 통해 UT 혹은 검증을 하기로 하였습니다. 따라서 대부분의 사용자가 팀원들과 친분이 있기에 서로의
note
내용을 보는 것에 대해 솔직한 마음 전달이 어려울 것이라고 판단하여note
의message
를 암호화 해야겠다고 합의가 되었습니다. 따라서 데이터 암호화를 할 것인지에 대해 논의하기 위해 Issue를 작성합니다.위의 이유로 privacy 보호를 위해 암호화 하는 것이 좋습니다. 하지만 우려되는 점은 개발 공수가 많이 들 수 있다는 것입니다.
현재 생각한 데이터 암호화 방법은 AES 입니다. AES는 클라이언트 측 암호화입니다. Firebase에서는 데이터는 전송중에 암호화되고 서버의 암호화된 디스크에 저장하며 암호화를 하지만, 앱 관리자는 Firebase 콘솔에서 데이터를 볼 수 있습니다. 따라서 관리자가 데이터를 읽지 못하는 것이 앱의 요구사항이 경우 Firebase에 보내기 전 클라이언트에서 암호화해야합니다.
구현 방법은 다음과 같습니다.
예시 코드는 아래에서 확인할 수 있습니다. 일단은 uuid를 통해 암호화 할 것으로 기대하여, uuid가 128bit이므로 AES128을 사용하는 것을 예시로 올리겠습니다. for JS: https://junhokims.tistory.com/10 for iOS: https://easy-coding.tistory.com/56
코드는 어렵지 않습니다. 하지만 현재 스프린트가 밀리고 있는 점, 웹(JS)이 주요 기술 스택인 팀원이 없어 더 어려움을 겪을 수 있는 점, 위의 내용은 일부분이고 예상치 못한 개발 공수가 늘어날 수 있는 점 등에서 현재 단계에서 데이터 암호화가 필요할지에 대해서 논의해보는 것이 좋을 것 같아 Issue 작성합니다.
이에 대한 의견 남겨주시면 감사하겠습니다.😊